[safe-output-health] Safe Output Health Monitor - 2026-07-30: 1 in-scope failure (LintMonster assign_to_agent, probable recurrence)

[github-actions[bot]]

Executive Summary

Audited 16 agentic workflow runs in the last ~5.5 hours (~2026-07-29T23:30Z..2026-07-30T04:56Z). 15/16 (93.75%) safe-output jobs completed cleanly. 1 in-scope hard failure: §30511498181 (LintMonster, run #82) - the safe_outputs job hard-failed at the "Process Safe Outputs" step while every other job in that run (activation, agent, detection, conclusion) succeeded.

The failure item shape (create_issuex3 + assign_to_agentx3 + create_discussionx1) strongly matches a previously-documented cluster from this same workflow - see Root Cause Analysis below. The exact error string could not be recovered (see Historical Context: observability gap).

Safe Output Job Statistics

Metric	Value
Total runs analyzed	16
safe_outputs jobs present	16
safe_outputs jobs success	15
safe_outputs jobs hard-failed (in scope)	1
Success rate	93.75%

Safe output type	Items emitted	Confirmed clean	In failed job (unconfirmed outcome)
create_issue	11	8	3
create_discussion	4	3	1
create_pull_request	3	3	0
add_comment	1	1	0
assign_to_agent	3	0	3

Error Clusters

Cluster: assign_to_agent_literal_issue_number_guess_unresolved (probable recurrence)

• Run: §30511498181 - LintMonster Proposal: Multi step workflows #82
• Failing job/step: safe_outputs -> "Process Safe Outputs" (duration 1.1m)
• Items in run: create_issue x3, assign_to_agent x3, create_discussion x1
• Signature: identical to the 2026-05-31 first sighting of this cluster (same workflow, same create-issues-then-assign-agent shape). That incidents confirmed root cause was the agent predicting/guessing sequential issue numbers for assign_to_agent instead of using #aw_<temporaryId> cross-references for issues it had just created in the same run, producing "Could not resolve to an Issue with the number of N" 404s.
• Confidence: PROBABLE, not CONFIRMED - the exact "Process Safe Outputs" stdout/stderr for this run could not be recovered (see Historical Context).
• Occurrence count: 2nd (2026-05-31 to 2026-07-30, ~60 days apart).

Root Cause Analysis

Primary hypothesis - LintMonster creates several issues in a single run and then calls assign_to_agent against them. If the agent references those issues by a guessed/predicted literal issue_number instead of the #aw_<temporaryId> cross-reference the safe-output processor resolves for other fields (proven working for create_issue body text), any off-by-N guess 404s at actuation. A secondary/compounding known defect in this same family: assign_to_agent hard-fails the whole job on an unresolvable target rather than soft-skipping a best-effort enrichment - so one bad guess fails the entire safe_outputs job, including the otherwise-successful create_issue/create_discussion items buffered in the same batch.

Confirmation blocker: the "Process Safe Outputs" step stdout/stderr is not pre-bundled into the downloaded run artifacts (run_summary.json records only step name + conclusion, no log body). Directly re-querying the audit tool against this run_id returned only a generic "Workflow Failed" / error_count: 1 finding - no step-level error text. This is a long-standing, previously-flagged gap (recurring across at least 6 prior audits for other clusters: 2026-06-23, 2026-06-26, 2026-07-11, 2026-07-20, 2026-07-23) that continues to prevent turning "probable" into "confirmed" for JOB-layer safe-output failures.

Recommendations

Immediate actions

1. Inspect the actual LintMonster workflow logs for run Proposal: Multi step workflows #82 (Actions UI) to confirm whether assign_to_agent again used guessed/predicted issue numbers instead of #aw_ temporary-id cross-references.
2. If confirmed, tighten the LintMonster prompt/guidance to explicitly forbid predicting issue numbers and always use temporary-id cross-references for issues created earlier in the same run.

Bug fixes (system-side, cross-cutting)

1. Resolve #aw_<temporaryId> references on the issue_number field of assign_to_agent the same way add_comment / create_pull_request already resolve them elsewhere.
2. Treat assign_to_agent as best-effort enrichment: on an unresolvable target, emit a warning and skip that single assignment rather than a job-failing error. The issues themselves were already created successfully - a failed auto-assignment should not red the whole run.
3. Highest priority, cross-cutting: pre-bundle the "Process Safe Outputs" step stdout/stderr into the run artifacts (or make it retrievable by the audit tool) on failure. This single change would let every future JOB-layer safe-output failure be root-caused directly instead of inferred from item-shape pattern-matching.

Process improvements

• Continue tracking day-by-day exercise of assign_to_agent to build a stronger recurrence signal - the 60-day gap between the 2 known occurrences makes trend detection slow; a confirmed 3rd occurrence would justify prioritizing the system-side fix over other open clusters.

Work Item Plans

#	Work item	Type	Priority	Owner hint
1	Pre-bundle "Process Safe Outputs" step stdout/stderr into run artifacts on failure	Observability infra	High (cross-cutting, blocks 6+ clusters)	safe-outputs runtime / log collection
2	Resolve #aw_<temporaryId> refs on assign_to_agent issue_number	Bug fix	Medium	safe_output_handler_manager.cjs assign handler
3	Soft-skip unresolvable assign_to_agent targets instead of hard-failing the job	Bug fix	Medium	safe_output_handler_manager.cjs assign handler
4	Audit LintMonster prompt for issue-number prediction guidance	Config/prompt review	Low-Medium	LintMonster workflow owner

Historical Context

This cluster (assign_to_agent_literal_issue_number_guess_unresolved) was first identified 2026-05-31 on the same workflow (LintMonster) with the same create-then-assign shape; today is its probable 2nd occurrence after ~60 days latent. In the interim, assign_to_agent was exercised cleanly multiple times (2026-06-01, 06-13, 06-16) using explicit real issue numbers rather than guesses, and a distinct sibling defect (assign_to_agent_missing_issue_pull_number_collection_rejected, collection-time field validation) was seen once on 2026-06-10.

The observability gap blocking exact-error confirmation is itself a recurring finding, previously flagged for: review_path_unresolved_422 (2026-07-20, 2026-07-23), changeset_generator_push_to_pull_request_branch_bundle_job_hardfail (2026-06-23, 2026-06-26), and firewall_report_process_safe_outputs_hardfail_create_discussion_not_wired (2026-07-11). No progress has been made on this fix across at least 6 audit cycles.

Other standing-open clusters (not exercised this window, no new data): review_path_unresolved_422 (unvalidated 58th consecutive audit), changeset_generator_push_to_pull_request_branch_bundle_job_hardfail (~34 days absent), target_star_add_comment_no_item_number_fallback / PR Sous Chef scheduled subvariant (PR Sous Chef did not run in this window).

Metrics and KPIs

• Safe-output job success rate: 93.75% (15/16), down from 100% (19/19) on 2026-07-29.
• Total safe-output items processed: 22 (11 create_issue, 4 create_discussion, 3 create_pull_request, 1 add_comment, 3 assign_to_agent).
• In-scope hard failures: 1 (vs. 0 on 2026-07-29, 2 on 2026-07-24).
• Distinct workflows observed: LintMonster, Sergo - Serena Go Expert, and others across the 16-run sample.

Next Steps

1. Pull the raw Actions-UI log for run #30511498181 to confirm the exact assign_to_agent error text and close the "probable to confirmed" gap.
2. Track whether this cluster recurs again within the next audit cycles; a 3rd occurrence would justify prioritizing the system-side fix.
3. Continue monitoring the still-unvalidated review_path_unresolved_422 and changeset_generator bundle-transport clusters for their next production exercise.

References:

• §30511498181 - LintMonster Proposal: Multi step workflows #82 (safe_outputs job hard failure, the headline finding of this audit)

Generated by 🔒 Safe Output Health Monitor · age00 · 376.8 AIC · ⌖ 18.8 AIC · ⊞ 9.7K · ◷

• expires on Jul 30, 2026, 9:36 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Safe Output Health Monitor.

A newer discussion is available at Discussion #49272.