The repositories field is hardcoded to ${{ github.event.repository.name }} and ignores the user-configured app.Repositories values. Compare to buildPreActivationAppTokenMintStep (compiler_pre_activation_job.go:665–675) which correctly handles single-repo, multi-repo, and org-wide (*) cases.

If a user supplies a non-default repository scope in their github-app: config, the minted token will silently ignore it. The same handling from the pre-activation step should be applied here:

if len(app.Repositories) == 1 && app.Repositories[0] == "*" {
    // org-wide: omit repositories field
} else if len(app.Repositories) == 1 {
    steps = append(steps, fmt.Sprintf("          repositories: %s\n", app.Repositories[0]))
} else if len(app.Repositories) > 1 {
    steps = append(steps, "          repositories: |-\n")
    for _, repo := range app.Repositories {
        steps = append(steps, fmt.Sprintf("            %s\n", repo))
    }
} else {
    steps = append(steps, "          repositories: ${{ github.event.repository.name }}\n")
}

@copilot please address this.

The mint step hardcodes only permission-actions: read and ignores the app.Permissions map that users may configure on the GitHubAppConfig struct. The other mint steps (e.g. the GitHub MCP step) forward extra permissions from the config. If this is intentional (guardrail only ever needs actions:read), that constraint should be enforced at parse time by rejecting permissions: on the AIC app config. Otherwise, the extra permissions should be merged here to be consistent with the rest of the app-token infrastructure.

@copilot please address this.

Double extraction: effective was already obtained by extractMaxDailyAICObjectValue(raw) on line 114, but it is then passed to isMaxDailyAICDisabled(effective) which calls extractMaxDailyAICObjectValue(effective) again internally. This is benign today (the second call is a no-op because effective is already a scalar), but it creates a confusing read and would silently misbehave if the logic ever changes.

Either have isMaxDailyAICDisabled accept a pre-unwrapped value and skip the internal extraction, or inline the check here and pass the already-unwrapped effective to a simpler helper.

@copilot please address this.

[/tdd] The repositories field configured on the github-app object is silently ignored — buildPreActivationAppTokenMintStep honours app.Repositories with a full multi-value path, but this step always emits the hardcoded current-repo value, creating a surprising behavioural gap. A test asserting that a configured repositories list appears in the compiled output would surface this.

if len(app.Repositories) == 1 && app.Repositories[0] == "*" {
    // org-wide: omit repositories field
} else if len(app.Repositories) == 1 {
    steps = append(steps, fmt.Sprintf("          repositories: %s\n", app.Repositories[0]))
} else if len(app.Repositories) > 1 {
    steps = append(steps, "          repositories: |-\n")
    for _, repo := range app.Repositories {
        steps = append(steps, fmt.Sprintf("            %s\n", repo))
    }
} else {
    steps = append(steps, "          repositories: ${{ github.event.repository.name }}\n")
}

@copilot please address this.

[/codebase-design] The data *WorkflowData parameter is accepted but never read inside this function — only app is used. This creates dead weight in the signature and makes the function's dependencies harder to understand at a glance.

func (c *Compiler) buildDailyAICAppTokenMintStep(app *GitHubAppConfig) []string {

steps = append(steps, c.buildDailyAICAppTokenMintStep(data.MaxDailyAICreditsGitHubApp)...)

@copilot please address this.

[/tdd] An app with ignore-if-missing: true but empty AppID/PrivateKey is silently discarded here. But resolveDailyAICToken specifically has an ignore-if-missing branch (combineTokenExpressions) that can never be reached from this extractor, since it always returns nil for such configs. There is no test covering this code path.

t.Run("object form with ignore-if-missing is preserved", func(t *testing.T) {
    frontmatter := map[string]any{
        "max-daily-ai-credits": map[string]any{
            "value": 5000,
            "github-app": map[string]any{
                "client-id":         "${{ vars.APP_ID }}",
                "private-key":       "${{ secrets.APP_KEY }}",
                "ignore-if-missing": true,
            },
        },
    }
    app := extractMaxDailyAICGitHubApp(frontmatter)
    if app == nil {
        t.Fatal("expected non-nil app when ignore-if-missing is set")
    }
    if !app.IgnoreIfMissing {
        t.Fatal("expected IgnoreIfMissing to be true")
    }
})

@copilot please address this.

[/codebase-design] The permission-actions: read permission is hardcoded here rather than derived from app.Permissions, which is the standard pattern for all other app token mint steps. This means users cannot extend or override permissions for the AIC guardrail app token (e.g., to add workflows: read if their guardrail script needs it in future).

@copilot please address this.

[/tdd] TestMaxDailyAICWithGitHubAppCompiledWorkflow verifies that the mint step appears in the compiled output, but doesn't verify the if: condition on that step. If the conditional (GH_AW_MAX_DAILY_AI_CREDITS != '') is wrong or absent, the token step would run unconditionally and fail in repos that don't set the guardrail — a regression this test would miss.

// Verify the mint step is gated on the guardrail env var being set
if !strings.Contains(lockStr, "if: ${{ env.GH_AW_MAX_DAILY_AI_CREDITS != '' }}") {
    t.Fatal("expected mint step to be gated on guardrail env var")
}

@copilot please address this.

[/tdd] There's no test for the object form disabled case (value: -1 in object form). The scalar isMaxDailyAICDisabled was updated to go through extractMaxDailyAICObjectValue, but there's no regression guard for the object form of -1.

t.Run("object form with value -1 is treated as disabled", func(t *testing.T) {
    got := resolveMaxDailyAIC(map[string]any{
        "max-daily-ai-credits": map[string]any{
            "value": -1,
        },
    }, "")
    if got != nil {
        t.Fatalf("expected nil (disabled) for object form value -1, got %v", got)
    }
})

@copilot please address this.

[/codebase-design] extractMaxDailyAICObjectValue returns nil when the raw value is an object without a value key — but callers like parseMaxDailyAICValue and isMaxDailyAICDisabled receive nil and silently treat the limit as unset. This means a malformed object form ({github-app: {...}} with no value) produces no validation error and no guardrail, which may surprise users.

@copilot please address this.