potiuk opened a new pull request, #211:
URL: https://github.com/apache/airflow-steward/pull/211
## Summary
Golden rule 4's prefetch plan already fires the GraphQL call for page N+1
in parallel with the maintainer's decision on page N — but the
classification of that data is still deferred to the page-turn moment,
adding "think time" at every page boundary. Classification is a pure
function over the already-fetched payload (no further GraphQL, no
prompts), so there is no reason to wait. This PR extends the prefetch
pipeline to also pre-classify *and* pre-render the first group of the
next page, so Step 5's page-turn collapses to a cache read.
## Changes
**`SKILL.md`**
- Golden rule 4 extended: pre-classification "rides along for free"
the moment the next-page payload arrives. Stash the bundle under
`prefetched_pages.<page_num>`.
- Step 5 split into prefetched / not-prefetched cases. Prefetched
branch collapses Steps 1 + 2 to a cache read.
**`interaction-loop.md`**
- Prefetch-plan table row for "Any group" points at a new
`Pre-classification and pre-rendering of the next page` subsection.
- New subsection documents the 3-step pipeline (turn N fires fetch,
turn N+1 classifies + groups + pre-renders, page-turn moment reads
cache) and per-PR invalidation via the existing optimistic-lock
head-SHA re-check.
**`fetch-and-batch.md`**
- "Prefetch plan" extended with a `Pre-classify on arrival` subsection
spelling out the 6-step post-arrival sequence (pre-filters → decision
table → Real-CI guard → grouping → pre-render → stash).
- Session-cache schema gains a `prefetched_pages.<n>` key carrying
`end_cursor`, `fetched_at`, `has_next_page`, and `groups[]` (each
with `classification`, `action`, `prs`, and `rendered_screen`).
- Invalidation list updated: per-PR head-SHA mismatch drops one tuple
and re-classifies inline; the rest of the bundle survives. Whole
bundle discarded on session exit.
## Design choices
- **Eager, not lazy.** Pre-classification fires the moment the next-page
payload lands, not at the page-turn. The whole point is to absorb the
classification latency into the maintainer's existing reading time.
- **First group only.** Pre-render the first group of the next page,
not every group. Subsequent groups stay cheap to render at
present-time, and the maintainer's path through them is uncertain.
- **One page ahead.** Kept the existing "no next-next-page prefetch"
budget rule from `fetch-and-batch.md` untouched.
- **Reuse the optimistic-lock guard.** A contributor push between
prefetch and execute invalidates the cached tuple via the same
head-SHA re-check Step 4 already runs. No new invalidation
machinery.
## Test plan
- [ ] `uv run --project tools/skill-validator --group dev skill-validate`
passes locally (verified — internal links to the new anchors resolve).
- [ ] Run `/pr-management-triage` against a repo with ≥ 2 pages of open PRs
and confirm:
- Page N+1's first group appears with no perceptible delay at the
page-turn.
- The session cache file under `/tmp/pr-management-triage-cache-*.json`
contains a `prefetched_pages.2` entry during page-1 interaction.
- [ ] Confirm a contributor push between prefetch and execute on one PR
drops just that PR's cached tuple (re-classified inline) and leaves the rest of
the bundle intact.
- [ ] Confirm `[Q]` on the current page leaves the prefetched bundle on disk
(cache file inspection) but the next session does not consume it (bundle is
discarded on session-exit / start).
Generated-by: Claude Code (Opus 4.7)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
