fullsend run: emit source/destination annotations for agent workflow runs

[ralphbean]

What happens

Agent workflow runs produce no structured metadata about which GitHub resources triggered them or which resources they acted on. Discovering this requires parsing workflow logs.

What should happen

Every agent workflow run should emit GitHub Actions annotations (::notice::) identifying:

• Source: the resource that triggered the run (e.g., ::notice title=Source::https://github.com/org/repo/issues/42). Exactly one per run.
• Destination: the resource(s) the agent produced or acted on (e.g., PRs created, reviews posted, issues updated). Zero or more per run, one annotation each.

These annotations surface via the Check Runs API (GET /repos/{owner}/{repo}/check-runs/{id}/annotations) as structured data, so API consumers can discover what resources an agent run was reacting to and what it produced — without parsing logs.

This maps to a stocks-and-flows model: the source is where the flow originates, the destination is where it lands. Annotations should use these terms consistently.

Context

• Annotations are not searchable/filterable via the GitHub API — you can't query "find runs that acted on issue Reposition fullsend as organization-agnostic framework #42." But they do give API consumers structured data to enumerate and match against, which is a significant improvement over log parsing.
• GitHub caps annotations at 50 per step; this should be well within limits.
• Related to the stocks-and-flows backlog issue.

[github-actions]

fullsend triage is working on this — view logs

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Enhancement

This issue requests structured metadata (GitHub Actions annotations) for agent workflow runs to identify which resource triggered the run (source) and which resources were produced (destinations).

Problem

Agent runs currently produce no machine-readable metadata linking runs to the GitHub resources they consume or produce. The only way to discover these relationships is to parse unstructured workflow logs.

Recommended Approach

1. Source annotation: Derive the triggering resource URL from the GitHub event payload (e.g., github.event.issue.html_url or github.event.pull_request.html_url) and emit it as ::notice title=Source::<url>. Exactly one per run.
2. Destination annotations: Emit ::notice title=Destination::<url> each time the agent creates or acts on a resource (PR, review, issue comment). Zero or more per run.
3. The likely implementation sites are the post-scripts (post-code.sh, post-fix.sh, etc.) and workflow dispatch files.

Relationship to Other Work

• Related to issue Model agent stocks and flows as a formal abstraction #356 (stocks-and-flows formal abstraction) — annotations would provide the runtime data that model needs.
• Related to issue Agent errors buried in transcript artifacts, not surfaced in workflow logs #704 / PR feat(#704): surface agent errors in workflow logs #764 (surfacing agent errors in workflow logs) — both improve structured observability of agent runs.

Proposed Test Case

Scenario: Code agent run emits source and destination annotations
  Given a code agent run triggered by issue #N
  When the run completes and creates PR #M
  Then the Check Runs API returns exactly 1 annotation with title "Source"
    and its message contains the issue URL
  And exactly 1 annotation with title "Destination"
    and its message contains the PR URL

Scenario: Triage agent run emits only source annotation
  Given a triage agent run triggered by issue #N
  When the run completes without creating new resources
  Then the Check Runs API returns exactly 1 "Source" annotation
    and 0 "Destination" annotations

Edge case: Verify annotation count remains within GitHub's
50-per-step cap for runs acting on many resources.