workflows: Snapshot native Issue dependencies

[idy]

Background

The reusable Issue Review workflow snapshots each native closing Issue's parent and sub-issue hierarchy, but its GraphQL queries omit GitHub's native blockedBy and blocking relationships. As a result, reviewers cannot see real dependency ordering and may report snapshot contains no dependency data even when GitHub has complete native relationships. h2vivi/firmwares#654 exposes the defect across closing Issues #642 and #649–#653, whose dependencies also reference #618 and #644.

Goal

Capture complete bounded native Issue dependency relationships in both the review input and the publication-time readiness verifier. Normalize the dependency snapshots deterministically, include them in Issue hashes and the enclosing readiness identity, and fail closed whenever GitHub reports more dependency relationships than were fetched.

Non-goals

• Do not ignore native dependency requirements.
• Do not relax Issue Review or PR readiness policy.
• Do not infer dependency relationships from Issue body text.
• Do not add pagination beyond GitHub's bounded 100-node relationship page.

Code Changes Tree

.github/
├── workflows/
│   └── codex-openai-review.yml             # query and map blockedBy/blocking totals and nodes for every closing Issue
└── scripts/
    ├── issue-review/
    │   ├── common.mjs                      # upgrade the Issue snapshot schema and normalize, deduplicate, sort, hash, and fail closed on dependencies
    │   └── test.mjs                        # cover dependency normalization, ordering, truncation blockers, and snapshot hash changes
    └── pr-readiness/
        ├── verify.mjs                      # refetch dependency relationships so publication verifies the same readiness identity
        └── test.mjs                        # cover workflow/verifier queries, dependency mapping, truncation, and stale readiness identity detection
README.md                                   # document bounded complete native dependency snapshots in the readiness contract

Design

GraphQL snapshot contract

For every node returned by closingIssuesReferences(first: 100), both the initial workflow query and pr-readiness/verify.mjs query blockedBy(first: 100) and blocking(first: 100). Each connection captures totalCount and nodes containing repository.nameWithOwner, Issue number, and state.

Normalization and schema

Upgrade ISSUE_REVIEW_SCHEMA_VERSION from 3 to 4. Map each dependency direction into an explicit count plus normalized node list. Convert state to uppercase, reject malformed references, deduplicate by case-insensitive repository plus Issue number, and sort by repository then Issue number. Preserve relationship direction; an Issue's blockedBy and blocking collections are not interchangeable.

Completeness and identity

If either dependency totalCount exceeds the corresponding normalized node count, add a deterministic fail-closed Issue-format blocker. The normalized dependency fields remain inside the Issue snapshot, so dependency additions, removals, state transitions, count changes, and direction changes alter the Issue snapshot SHA-256 and therefore the enclosing PR readiness snapshot identity. The publication verifier must map the same fields before comparing EXPECTED_SNAPSHOT_SHA256.

Test And Acceptance Criteria

Acceptance Criteria

• Issue Review input for h2vivi/firmwares#654 directly contains the native blockedBy and blocking relationships among #642, #649–#653, #618, and #644.
• The reviewer no longer reports snapshot contains no dependency data when those native GitHub relationships exist.
• Dependency nodes are deduplicated and deterministically ordered by repository and Issue number.
• Dependency state and relationship changes invalidate the Issue snapshot hash and PR readiness identity.
• Either dependency connection fails closed when totalCount exceeds the number of collected normalized nodes.
• Existing hierarchy completeness and review-policy requirements remain enforced.

Validation

• node .github/scripts/issue-review/test.mjs
• node .github/scripts/pr-readiness/test.mjs
• node .github/scripts/pr-review/test.mjs
• node --check .github/scripts/issue-review/common.mjs
• node --check .github/scripts/pr-readiness/verify.mjs
• git diff --check
• Re-run Issue Review for h2vivi/firmwares#654 and inspect the emitted Issue snapshot/review result for the live dependency relationships.