[uk-ai-resilience] [security] Fix actionlint codegen regression: 69 workflows reference undeclared secret_verification_result ou [Content truncated due to length]

[github-actions]

Summary

The gh-aw compiler emits if: conditions in generated .lock.yml files that reference needs.<job>.outputs.secret_verification_result, but the producing job never declares that output. This is a real compiler codegen defect — Tier B under UK AI Open Code Governance.

Evidence

From the 2026-07-20 static analysis report (#46721):

• Tool: actionlint
• Count: 69 generated workflows affected
• Error: [expression] property "secret_verification_result" is not defined in object type {...}
• Historical trend: count crept from 109 → 114 over the past week, with this regression as the dominant contributor

Sample workflows affected: ab-testing-advisor, agent-performance-analyzer, archie, architecture-guardian, artifacts-summary, auto-triage-issues, brave, breaking-change-checker, ci-coach, cli-consistency-checker... (69 total)

Impact

• Dangling if: output reference evaluates to empty string — the intended guard may not behave as designed
• Silences actionlint signal across 69 workflows, reducing detection of real issues
• Indicates a compiler regression (previously tracked as closed [static-analysis] actionlint [expression] regression: undefined secret_verification_result output in 69 workflows #44870)

Remediation

Fix the generator in pkg/workflow (search for secret_verification_result):

Option A: Declare the output on the producing job:

outputs:
  secret_verification_result: ${{ steps.<step>.outputs.result }}

Option B: If secret verification was removed, delete the dangling if: reference from the consuming job.

Then recompile all workflows and verify:

make recompile && actionlint .github/workflows/*.lock.yml 2>&1 | grep -c secret_verification_result
# must be 0

Add a compiler unit test asserting every emitted needs.*.outputs.* reference has a matching outputs: declaration.

Risk Scoring (UK AI Governance)

Dimension	Score
Exposure amplification (AI generates workflows)	3/5
Patchability	2/5 (fix generator, then recompile)
Detectability	2/5
Operational fragility	2/5
Ownership confidence	2/5
Overall	2.2 — Tier B

SLA

High — resolve within 7 days.

References

• Static analysis report: [static-analysis] Report - 2026-07-20 #46721
• Previously tracked: [static-analysis] actionlint [expression] regression: undefined secret_verification_result output in 69 workflows #44870 (closed)
• §29757682067

Generated by UK AI Operational Resilience · 100.9 AIC · ⌖ 5.86 AIC · ⊞ 5.2K · ◷

[bryanchen-d]

This was generated by AI during triage.

Confirmed this still affects workflows compiled with gh-aw v0.82.14.

In microsoft/vscode-engineering#3364, all six newly compiled error workflows fail the repository's generated-lock actionlint gate with:

property "secret_verification_result" is not defined in object type

CI run: https://github.com/microsoft/vscode-engineering/actions/runs/29870174366

The six affected locks are:

• errors-triage.lock.yml
• errors-regression-scan.lock.yml
• errors-stable-scan.lock.yml
• errors-investigate.lock.yml
• errors-fix.lock.yml
• errors-fix-driver.lock.yml

gh aw validate reports zero errors locally, so this currently reaches downstream actionlint rather than being rejected by the compiler's own validation. It blocks adopting the latest released compiler in a repository that treats generated-lock expression errors as merge-blocking.

[bryanchen-d]

This was generated by AI during triage.

I traced the current compiler source and need to correct my earlier assumption:
this is not fixed on main, and the v0.83.0 prerelease still contains the
unconditional reference.

The regression was introduced by #44777:

#44777

Current buildConclusionJobCondition always adds:

secretVerificationFailed := BuildEquals(
    BuildPropertyAccess("needs.activation.outputs.secret_verification_result"),
    BuildStringLiteral("failed"),
)

Current source:

gh-aw/pkg/workflow/notify_comment_conclusion_helpers.go

Lines 472 to 489 in 2868d6e

	// buildConclusionJobCondition builds the condition guarding the conclusion job.
	func buildConclusionJobCondition(data *WorkflowData, mainJobName string, safeOutputJobNames []string) ConditionNode {
	// Build the condition for this job:
	// 1. always() - run even if agent fails
	// 2. agent was activated (not skipped) OR lockdown check failed in activation job
	// 3. IF comment_id exists: add_comment job either doesn't exist OR hasn't created a comment yet
	alwaysFunc := BuildFunctionCall("always")
	agentNotSkipped := BuildNotEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.result", mainJobName)), BuildStringLiteral("skipped"))
	lockdownCheckFailed := BuildEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.lockdown_check_failed", constants.ActivationJobName)), BuildStringLiteral("true"))
	oauthTokenCheckFailed := BuildEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.oauth_token_check_failed", constants.ActivationJobName)), BuildStringLiteral("true"))
	staleLockFileFailed := BuildEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.stale_lock_file_failed", constants.ActivationJobName)), BuildStringLiteral("true"))
	secretVerificationFailed := BuildEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.secret_verification_result", constants.ActivationJobName)), BuildStringLiteral("failed"))
	activationGuardrailsFailed := BuildOr(lockdownCheckFailed, BuildOr(oauthTokenCheckFailed, BuildOr(staleLockFileFailed, secretVerificationFailed)))
	if hasMaxDailyAICGuardrail(data) {
	dailyAICExceeded := BuildEquals(BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.daily_ai_credits_exceeded", constants.ActivationJobName)), BuildStringLiteral("true"))
	activationGuardrailsFailed = BuildOr(activationGuardrailsFailed, dailyAICExceeded)
	}
	condition := BuildAnd(alwaysFunc, BuildOr(agentNotSkipped, activationGuardrailsFailed))

However, the compiler intentionally omits validate-secret and the activation
output when a top-level environment is configured. That behavior already has a
test:

https://github.com/github/gh-aw/blob/2868d6e080ff76e594e79cafbdfacd11bfa53d2b/pkg/workflow/secret_verification_output_test.go

The environment-variable forwarding path correctly checks
EngineHasValidateSecretStep(engine, data) before referencing the output, but
the conclusion condition does not.

A regression test should compile a workflow with both:

environment: production
safe-outputs:
  add-comment:

and assert that its conclusion condition does not reference
needs.activation.outputs.secret_verification_result.

Would the maintainers confirm whether a fix is planned? This remains the sole
required-check blocker for microsoft/vscode-engineering#3364. Runtime validation
is otherwise green:

https://github.com/microsoft/vscode-engineering/actions/runs/29938666136

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: The service is temporarily unavailable. Please try again later. (Request id: 0D96:1C2D55:DF80A2:E44387:6A63BB92)

[lpcox]

Confirmed on main (verified against current source). Adding some additional context and a concrete fix outline.

Root cause: an asymmetric guard

There are two consumers of needs.activation.outputs.secret_verification_result in the conclusion job, and only one of them is guarded.

The output itself is conditionally declared — it's only added to the activation job when the engine emits a validate-secret step (pkg/workflow/compiler_activation_steps.go:44):

func (c *Compiler) addActivationSecretValidationStep(ctx *activationJobBuildContext) {
    secretValidationStep := ctx.engine.GetSecretValidationStep(ctx.data)
    if len(secretValidationStep) == 0 {
        return // no output declared
    }
    ...
    ctx.outputs["secret_verification_result"] = "${{ steps.validate-secret.outputs.verification_result }}"
}

Consumer 1 — the env var — correctly mirrors that guard (notify_comment_conclusion_helpers.go:217):

if EngineHasValidateSecretStep(engine, data) {
    envVars = append(envVars, "...GH_AW_SECRET_VERIFICATION_RESULT: ${{ needs.activation.outputs.secret_verification_result }}...")
}

Consumer 2 — the if: condition — references it unconditionally (notify_comment_conclusion_helpers.go:483):

secretVerificationFailed := BuildEquals(
    BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.secret_verification_result", constants.ActivationJobName)),
    BuildStringLiteral("failed"))
activationGuardrailsFailed := BuildOr(lockdownCheckFailed, BuildOr(oauthTokenCheckFailed, BuildOr(staleLockFileFailed, secretVerificationFailed)))

So whenever GetSecretValidationStep returns empty, the output is never declared but the condition still points at it → the dangling reference actionlint flags.

When the output is omitted

Per EngineHasValidateSecretStep / GetSecretValidationStep, the validate-secret step (and therefore the output) is dropped when:

• a custom engine is used (BaseEngine never emits the step), or
• a custom command is set on the engine, or
• for Copilot, when permissions.copilot-requests is write.

The environment: interaction the earlier comment observed lands in the same bucket for the affected repos — those configs route to an engine setup that doesn't emit validate-secret, so the output disappears while the condition keeps referencing it.

Why gh aw validate stays green

The compiler's own validation doesn't verify that emitted needs.<job>.outputs.<name> references resolve to a declared output, so this only surfaces at downstream actionlint. That's the reason it reaches merge-blocking gates in consuming repos (e.g. microsoft/vscode-engineering#3364) rather than being caught at compile time.

Fix outline

1. Thread the engine into the condition builder. buildConclusionJobCondition (currently a free function taking data, mainJobName, safeOutputJobNames) should become a *Compiler method (or take the resolved engine) so it can call EngineHasValidateSecretStep, exactly like the env-var path already does via c.getAgenticEngine(data.AI). The sole caller at notify_comment.go:92 is already on the *Compiler receiver.

2. Guard the clause. Only include secretVerificationFailed in activationGuardrailsFailed when EngineHasValidateSecretStep(engine, data) is true:

   guardrails := BuildOr(lockdownCheckFailed, BuildOr(oauthTokenCheckFailed, staleLockFileFailed))
   if EngineHasValidateSecretStep(engine, data) {
       secretVerificationFailed := BuildEquals(
           BuildPropertyAccess(fmt.Sprintf("needs.%s.outputs.secret_verification_result", constants.ActivationJobName)),
           BuildStringLiteral("failed"))
       guardrails = BuildOr(guardrails, secretVerificationFailed)
   }

   This keeps the guard behavior intact for engines that do verify secrets and simply omits the dangling term when they don't.

3. Add a regression test next to secret_verification_output_test.go: compile a workflow that omits the validate-secret step (e.g. custom engine, or environment: + safe-outputs: add-comment:) and assert the conclusion if: contains no secret_verification_result reference. Complement with a positive case asserting the reference is present for a standard Copilot/Claude config.

4. Recompile + verify the whole tree:

   make recompile
   actionlint .github/workflows/*.lock.yml 2>&1 | grep -c secret_verification_result   # must be 0

5. (Optional, prevents recurrence) Add a compiler-level check asserting every emitted needs.*.outputs.* reference has a matching declared outputs: entry on the producing job, so a future asymmetry fails gh aw compile instead of leaking to downstream actionlint.

Regression was introduced by #44777.