# React On Rails Release Train Issue Evaluation

> Use when evaluating React on Rails GitHub issues for release-train targeting, especially deciding whether new, follow-up, or non-started issues belong on release/17.0.0, another release/X.Y.Z branch, or main.

- Skill: `shakacode/react-on-rails-release-train-issue-evaluation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shakacode/react-on-rails-release-train-issue-evaluation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shakacode/react-on-rails-release-train-issue-evaluation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: shakacode (https://skillmd.com/u/shakacode)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shakacode/react-on-rails-release-train-issue-evaluation

---


# React on Rails Release Train Issue Evaluation

## Core Rule

Use this with `$evaluate-issue`. That skill answers "is this worth doing?"; this skill answers "does it belong on the active release train or on `main`?"

`release/*` receives only stabilizing fixes. Features, cleanup, docs, process work, non-blocking hardening, and ordinary follow-ups target `main`.

## Backport Shape

The runbook's **BLOCKED** compound-release boundary is an operational and agent
policy stop, not runtime enforcement. The tasks remain technically callable in
live mode; direct live invocation outside the individually guarded procedure
violates release policy.

When one or more merged `main` PRs qualify for `release/X.Y.Z`, default to one
source PR per release backport PR:

- Before branching, search open release-targeted PRs, targeted private
  coordination for the source, and remote branches with verified ownership and
  source binding. Reuse or skip a valid source-atomic lane, or an explicitly
  maintainer-approved aggregate whose sources meet the inseparability exception
  below. Stop rather than duplicate work when a candidate branch's ownership or
  source binding is `UNKNOWN`. If an unapproved aggregate violates this shape,
  recommend separate replacements; close it only with explicit write
  authorization and retain its branch unless deletion is also authorized.
- Process them serially under the canonical `release-line:X.Y.Z` coordination
  lease defined in the release-train runbook, held by one dedicated release
  coordinator across discovery, validation, and merge. Every writer targeting
  that release branch, including a release-first stabilizing fix or metadata PR,
  must participate in the same lease; source-scoped claims do not provide this
  serialization. Chain later batch lanes with `depends_on`, and do not launch
  them until the preceding merge is terminal. A writer that cannot participate
  in the canonical lease must stop; the repository's merge-group CI does not
  rerun source-liveness, provenance, attribution, manual QA, or review gates and
  is not an alternative. Refresh the dedicated heartbeat at the runbook cadence
  during long gates, and immediately before merge require the canonical claim to
  be active, unexpired, and owned by the expected coordinator with a live
  matching heartbeat. Stop if the guard is unavailable or its state is
  `UNKNOWN`. Merge one release-targeted change,
  fetch the new release tip, then update a reused PR onto that tip or branch the
  next. Rerun validation, QA, and review on the updated head before merging.
- Before updating or branching, confirm each selected source patch is still live
  on explicitly fetched `origin/main`. A source reverted or superseded on `main`
  requires renewed maintainer approval before backporting. Repeat this check and
  the release-tip check immediately before merge; update and rerun validation,
  QA, and review if either relevant ref changed.
- Before every RC cut or re-spin, final promotion, and release closeout, fetch
  `origin/main` and revalidate every retained main-origin backport. A source
  patch that is no longer live is a blocker until a maintainer explicitly
  reapproves retaining it in the release. During closeout, do not let the
  forward-port helper automatically reapply reverted or superseded origins;
  stop for explicit manual dispositions and use the runbook's selective manual
  closeout path plus its complete omitted-pick manifest when the disposition is
  to omit or replace one or more picks.
- Treat `BACKPORT_SOURCE_AUDIT_RESULT` and selective-closeout manifest proof,
  approval, and replacement-disposition fields as structured attestations. They
  do not prove the underlying semantic facts. Before accepting them, the maker
  and independent checker must each re-derive the audit against the exact
  fetched tips and separately verify approval authorship, repository permission,
  and trust from the live authenticated record. Stale, inaccessible, untrusted,
  or `UNKNOWN` evidence remains fail-closed.
- Give each source PR its own `git cherry-pick -x` provenance, conflict record,
  validation, QA evidence, review cycle, and rollback boundary. Every commit
  created by a `main`-to-release backport and landed on the release branch must
  have exactly one direct
  `(cherry picked from commit <source-sha>)` footer; record inherited provenance
  from a source commit in the PR instead of copying another footer. A backport
  with exactly one source commit must be squash-merged with a final subject
  ending in `(#<backport-pr-number>)` and that footer in the commit body; rebase
  merge is unsupported because an unattributed source subject can make the
  changelog sweep report `UNKNOWN`. For a multi-commit rebase-merged source PR
  or approved aggregate, stop for a
  maintainer-approved merge plan until the repository can preserve both one
  normalized release commit per source commit and changelog-sweep PR
  attribution; never create a multi-footer commit.
- Do not bundle independent source PRs because they share a target, component,
  milestone, or `CHANGELOG.md`. Shared changelog edits require serialization;
  retain each source PR's applicable changelog entry, then reconcile the entries
  and stamp or regenerate the RC changelog after every backport retained in the
  final release set lands.
- Combine only behaviorally inseparable changes that cannot be reviewed,
  tested, or reverted safely alone. Require an explicit maintainer-approved
  rationale naming every source PR before implementation.

## Workflow

1. Refresh repo context: fetch and prune `origin/main` and the target release
   branch, then run `.agents/bin/agent-workflow-seam-doctor`. Use the refreshed
   release ref for ancestry, prior-backport, and supersession checks.
2. Resolve candidates from live GitHub. For strict 48-hour windows, search by date then timestamp-filter locally because GitHub search is date-granular.
3. Exclude started lanes. For an ordinary issue candidate, an assignee,
   linked/open implementation PR, private claim/heartbeat/branch, or
   implementation comment means the lane is started. A merged `main` source PR
   is completed input, not a started release-backport lane: its linked issue,
   assignee, merged implementation PR, and generic source coordination state do
   not exclude it. Its backport lane is started by a valid source-atomic
   release-targeted implementation PR or branch; an explicitly
   maintainer-approved aggregate whose sources are behaviorally inseparable; a
   backport implementation comment for either valid shape; or private
   coordination state that explicitly identifies that valid release/backport
   lane. An unapproved, shape-violating aggregate does not exclude its source
   candidates; keep them eligible so the **Backport Shape** replacement can be
   recommended.
   Run `agent-coord doctor --json`, then run
   `agent-coord status --repo shakacode/react_on_rails --target <issue-or-pr> --json`
   for each candidate. Dead or expired ordinary-issue claims and explicitly
   identified backport claims count as started-but-stalled, not non-started;
   generic source claims do not prove that a backport started.
4. Read release context: active `Release gate:` tracker, `release` + `TRACKING` labels, the `Agent Release Mode` block, `agent-coord` phase when available, source PR base branches, and whether source commits are already on `origin/release/X.Y.Z`.
5. Evaluate each candidate with `$evaluate-issue`: evidence source, impact, complexity, process gap disposition, and priority.
6. Choose the target:
   - `release/X.Y.Z`: verified RC/final stabilizer such as an RC regression, hard-gate failure, install/upgrade blocker, security/data-loss/wrong-output bug, release-branch CI/release tooling blocker, or final-only public API/breaking-change decision.
   - `release/X.Y.Z contingent`: only needed if maintainers decide to cherry-pick a related main-only fix into the train. Name the dependency.
   - `main`: docs, changelog for main-only PRs, CI/tooling hygiene, tests, process automation, non-blocking runtime hardening, features, and performance/cleanup without release-gate proof.
   - `park/close`: P3, speculative, duplicate, no-PR evidence, or not worth doing.
7. For one or more `release/X.Y.Z` selections, apply the **Backport Shape**
   rules above. For multiple selections, also record the serial order.

Recommend labels/milestones/comments, but do not mutate GitHub unless the user explicitly authorizes writes.

## Output

Use a compact table:

| Issue | Started? | Evidence | Disposition | Target | Rationale | Next action |
| ----- | -------- | -------- | ----------- | ------ | --------- | ----------- |

Call out `UNKNOWN` facts explicitly, especially release tracker mode, source PR base, branch ancestry, and whether the issue is a confirmed RC regression.

## Common Mistakes

- Treating a title that says "before 17.0.0 final" as sufficient. Verify release-gate impact and branch ancestry.
- Sending main-only follow-up defects to `release/17.0.0` when the related fix is not on the release branch. Mark these contingent instead.
- Using labels alone. Labels are hints; issue evidence and the release tracker decide.
- Treating tracker `Mode: development` as "no release train." The branch can still exist; target selection still matters.