fix: correct integrity level descriptions and auto-enable cli-proxy for reactions

[lpcox]

Summary

Three related fixes for integrity filtering documentation and compiler behavior:

1. Fix incorrect min-integrity: unapproved descriptions

The maintaining-repos guide (merged in #26073) incorrectly described unapproved as allowing "all community content — first-time contributors, external users, everyone." That is the behavior of min-integrity: none.

Fixed three locations to accurately describe unapproved as including CONTRIBUTOR and FIRST_TIME_CONTRIBUTOR while filtering out FIRST_TIMER and NONE association users.

2. Compiler: implicitly enable cli-proxy when integrity-reactions: true

Reaction-based integrity decisions require the CLI proxy to identify reaction authors. Previously, users had to set both features.integrity-reactions: true and features.cli-proxy: true manually. The compiler now automatically enables the CLI proxy when integrity-reactions is enabled.

Changes:

• isCliProxyNeeded() in compiler_difc_proxy.go: also returns true when integrity-reactions feature flag is set
• collectDockerImages() in docker.go: includes cli-proxy image when either cli-proxy or integrity-reactions is enabled
• Added 6 new test cases in compiler_difc_proxy_test.go

3. Docs: describe compiler defaults for integrity-reactions (available in v0.68.2)

Rewrote the "Reactions as Trust Signals" section to describe what the compiler injects automatically rather than showing explicit frontmatter for endorsement-reactions, disapproval-reactions, endorser-min-integrity, and disapproval-integrity. Users only need:

features:
  integrity-reactions: true
tools:
  github:
    min-integrity: approved

The compiler handles the rest:

• Enables CLI proxy (required for reaction author identification)
• Injects default endorsement reactions: THUMBS_UP, HEART
• Injects default disapproval reactions: THUMBS_DOWN, CONFUSED
• Uses endorser-min-integrity: approved (MCPG default)
• Uses disapproval-integrity: none (MCPG default)

Also added a clear warning that reactions only work in proxy mode — gateway mode cannot identify reaction authors.

Test Plan

• New tests: TestIsCliProxyNeeded_IntegrityReactionsImplicitEnable (6 cases) — all pass
• Existing tests: TestCollectDockerImages_CliProxy (4 cases) — still pass
• Existing tests: TestHasDIFCProxyNeeded (10 cases) — still pass
• Race detector: all related tests pass with -race
• make recompile: 191/191 workflows compiled, no lock file changes (existing workflows don't use integrity-reactions)

[Copilot]

Pull request overview

Fixes integrity filtering documentation inaccuracies and updates the compiler to better support reaction-based integrity decisions by ensuring CLI-proxy-related components are included when integrity-reactions is enabled.

Changes:

• Corrects min-integrity: unapproved descriptions in the maintainer guide.
• Updates Docker image collection and CLI-proxy “needed” logic to consider integrity-reactions.
• Adds unit tests covering implicit CLI-proxy enablement behavior.

Show a summary per file

File	Description
pkg/workflow/docker.go	Pulls the cli-proxy AWF image when integrity-reactions (or cli-proxy) is enabled.
pkg/workflow/compiler_difc_proxy.go	Treats integrity-reactions as implying CLI-proxy is needed (when firewall + version support).
pkg/workflow/compiler_difc_proxy_test.go	Adds test cases for implicit CLI-proxy enablement via integrity-reactions.
docs/src/content/docs/guides/maintaining-repos.md	Fixes unapproved integrity descriptions and rewrites the reactions section to describe compiler defaults.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (2)

docs/src/content/docs/guides/maintaining-repos.md:229

• This section states the compiler will automatically enable the CLI proxy and that a warning is logged when integrity-reactions is enabled in gateway mode. With the current code changes, only isCliProxyNeeded/image pulling consider integrity-reactions; other behavior is still gated by features.cli-proxy, and gateway-mode warnings currently only trigger when reaction fields are explicitly present in the tool config. Either adjust the docs to match actual behavior, or expand the compiler/runtime so integrity-reactions truly forces proxy mode (and emits the described warning when it can’t).

The compiler handles the rest — when `integrity-reactions: true` is set, it automatically:

- Enables the CLI proxy (`cli-proxy: true`), which is required for reaction-based integrity decisions
- Injects default endorsement reactions: `THUMBS_UP`, `HEART`
- Injects default disapproval reactions: `THUMBS_DOWN`, `CONFUSED`
- Uses `endorser-min-integrity: approved` (only reactions from owners, members, and collaborators count)
- Uses `disapproval-integrity: none` (a disapproval reaction demotes content to `none`)

These defaults mean that when a trusted member (owner, member, or collaborator) adds a 👍 or ❤️ reaction to an issue or comment, the item's integrity is promoted to `approved` — making it visible to agents using `min-integrity: approved`. Conversely, a 👎 or 😕 reaction from a trusted member demotes the item to `none`.

See the [Integrity Filtering Reference](/gh-aw/reference/integrity/) for complete configuration details.

## Scaling Strategies

pkg/workflow/compiler_difc_proxy.go:361

• isCliProxyNeeded now treats integrity-reactions as implicitly enabling the CLI proxy, but the rest of the compilation path still gates CLI-proxy behavior on features.cli-proxy only (e.g., AWF args --difc-proxy-host/--difc-proxy-ca-cert, skipping GitHub MCP server registration, gh CLI guidance, GH_TOKEN exclusion). As-is, a workflow with only integrity-reactions: true will start the host proxy step but AWF will not start/connect the cli-proxy sidecar, so reaction-based integrity decisions still won't be effective. Consider introducing a single "effectiveCliProxyEnabled" check (cli-proxy || integrity-reactions) and using it everywhere the cli-proxy flag is currently checked, or actually injecting cli-proxy: true into WorkflowData.Features during compilation when integrity-reactions is enabled.

	cliProxyEnabled := isFeatureEnabled(constants.CliProxyFeatureFlag, data)
	integrityReactionsEnabled := isFeatureEnabled(constants.IntegrityReactionsFeatureFlag, data)

	if !cliProxyEnabled && !integrityReactionsEnabled {
		return false
	}
	if integrityReactionsEnabled && !cliProxyEnabled {
		difcProxyLog.Print("integrity-reactions enabled: implicitly enabling CLI proxy")
	}
	if !isFirewallEnabled(data) {
		return false
	}
	firewallConfig := getFirewallConfig(data)
	if !awfSupportsCliProxy(firewallConfig) {
		difcProxyLog.Printf("Skipping CLI proxy: AWF version too old")
		return false
	}
	return true

• Files reviewed: 4/4 changed files
• Comments generated: 2

[Copilot]

collectDockerImages uses the same cli-proxy || integrity-reactions condition as isCliProxyNeeded, but other runtime wiring for cli-proxy is still gated solely on features.cli-proxy (AWF flags, env exclusions, etc.). Until those other call sites also treat integrity-reactions as enabling cli-proxy, this can lead to pulling the cli-proxy image even though the cli-proxy sidecar won't actually be started/used. Align the condition across the whole cli-proxy pipeline (ideally via a shared helper) so image pulling matches actual runtime usage.

[Copilot]

This test calls isFeatureEnabled via isCliProxyNeeded, which can read GH_AW_FEATURES from the environment. To keep the test hermetic (and avoid failures when GH_AW_FEATURES is set in a developer’s shell/CI), explicitly clear or set GH_AW_FEATURES (e.g., t.Setenv("GH_AW_FEATURES", "")) at the start of the test.