Every run should produce exactly one summary per remediation unit, reflecting the unit's final state for that run (not one entry per iteration of the exhaustive loop).
generated_at: ISO 8601 UTC timestamp for whenlatest.jsonwas renderedfinished_at: ISO 8601 UTC timestamp for when the locked remediation run finished- profile name
- GitHub owner
- active repository count
- manual-only repository count
- sanitized open alert counts by alert class, when available
- repository name
- repository visibility, when public issue output may include repository detail
- base branch
target_id- remediation dedup key
- alert class
- rule id, when the alert class is
code_scanning - alert number, when the alert class is
secret_scanning - incident triage state, when the alert class is
secret_scanning - PR source: native_dependabot or agent_managed
- pass type: remediation or merge
- outcome
- pull request link, if any
- reason code, if any
- remaining blocker, if any
- platform constraints, when they explain operator action or review-required handling
- manual follow-up actions, if any
merged: remediation completed and was mergedopened_pr: remediation committed to a remediation branch, pushed, and PR opened or updatedblocked: remediation is prepared or known, but policy or environment prevents completionskipped: intentionally not processedfailed: execution error or unrecoverable tooling problem
- summarize all processed remediation units
- report all skipped repository entries with the reason
- report all blocked units with the specific blocker
- report any reason code using the closed reason-code vocabulary defined in
docs/operating-model.md - distinguish unsupported alert classes from execution failures
- do not mark a unit
mergedunless the actual merge completed - report remaining open
Dependabotalerts after the exhausted run and explain whether they are waiting onopened_pr, blocked by policy or environment, or outside current remediation scope - report remaining open
code scanningalerts by rule and explain whether they are unsupported, blocked by policy, disabled at the repository level, or missing analysis - report remaining open
secret_scanningalerts with their incident triage state and required manual follow-up actions, and explain whether they are awaiting cleanup PR review, blocked by policy, or disabled at the repository level - surface relevant
platform_constraintsfor manual-only, review-required, or env-mismatch cases when they explain the operator action needed - if the weekly renderer uses a GitHub security overview fallback, include only sanitized aggregate open-alert counts by class and make clear they are dashboard counts, not remediation results
- public weekly issue output may include repository names and PR links only for remediation units explicitly marked public
- private or unknown-visibility repositories must be collapsed into aggregate counts only
- public weekly issue output must never include private repository names, secret types, alert numbers, raw alert payloads, or token-like strings
- weekly issue rendering should use
Patched by automationfor PRs created, updated, or merged by the run andManual review requiredfor items that need human attention - weekly issue rendering should lead with a compact
Run summaryshowing initial alert totals by class, patched-by-automation totals, PRs created or updated, auto-merged totals, remaining manual-review totals, and current GitHub open-alert totals