Filter trigger-only commits out of Crane iteration summaries

Start with workflows/crane.md and inspect the existing prompt-test setup mentioned in the issue. Update the accepted-iteration guidance and add a test covering the trigger-commit wording; done means trigger commits are ignored when substantive commits exist, but linked when they are the only commit.

Background

In githubnext/apm, Crane sometimes produced or encountered process-only commits such as ci: trigger checks. Those commits are useful to make CI run, but they are not the accepted migration work. If Crane summarizes that commit as the latest change, reviewers get a misleading PR update.

APM updated its local Crane prompt to ignore ci: trigger checks when selecting the commit to link in an accepted iteration summary, unless that trigger commit is the only new commit available.

Problem

Long-running migration PRs can accumulate commits that are not substantive migration changes:

• CI trigger commits.
• Empty or near-empty process commits.
• Retry commits whose only purpose is to wake checks.

If the PR body or PR comment points at one of those instead of the actual accepted migration commit, the update says little about the work that landed. This was one reason the APM Crane PR looked stale or untrustworthy from the review surface.

Proposed implementation

Update the accepted-iteration summary guidance in workflows/crane.md so the commit selection rule is explicit:

• Link the real accepted migration commit when available.
• Ignore a commit with subject exactly ci: trigger checks when another new substantive commit exists.
• Consider documenting a small ignore-list for future process-only subjects, for example ci: trigger checks and chore: trigger checks.
• If a trigger-only commit is the only new commit, link it but state that no substantive migration commit was found.

This should apply anywhere Crane chooses a short SHA for:

• PR comments.
• PR body updates.
• Migration issue comments.
• Repo-memory iteration history.

Implementation notes

This can start as prompt guidance only. If Crane later moves summary generation into code, expose the ignore-list as a small function with test coverage.

Suggested prompt wording:

Commit short SHA linked to the commit URL, ignoring a `ci: trigger checks` commit unless it is the only new commit.

Suggested test coverage

Add a prompt test asserting that workflows/crane.md contains:

• ci: trigger checks
• unless it is the only new commit

If summary generation becomes code-backed, add table tests for:

• one substantive commit
• trigger commit plus substantive commit
• trigger commit only
• multiple substantive commits plus trigger commit

Acceptance criteria

• Crane PR comments and issue comments do not present CI trigger commits as the migration change.
• Process-only commits can still be linked when they are genuinely the only commit.
• The behavior is documented and guarded by tests.

Provenance

This came from githubnext/apm migration review, where maintainers needed comments to explain the new accepted Crane commit, not a CI wake-up commit.