syntaqxAn open pull request's page no longer asks repos whether it is behind a second time, and anyone's ready pull request says it is ready to merge. Signed in, flagon-io/g1t #41 took 5 to 10 seconds and once failed: get_pull worked out whether it is behind (stored with its mergeability for its head, as merge_choices does), then the merge gate asked repos `behind` again on every view, a walk of the git store that took up to 5 s (Workers Logs: /rpc/behind 4.9 s, 649 ms CPU). The gate now takes what the page already worked out (merge_gate_seen), as does the lifecycle's own gate; merging and the queue still ask repos as they did. And the lifecycle was worked out only for pull requests g1t's agent made (managed = 1), which since g1t stopped running agents of its own is none, so a person's pull request that met everything its branch asks for (#41: CI passed, no approvals required) said nothing about being ready. Every open pull request now gets one; only one g1t manages merges by itself (auto_merge is gated on managed), and anyone else's draft still gets none, so its page does not keep refreshing. Lists keep showing a lifecycle only for managed pull requests, since nothing yet refreshes a stored one for the rest. Checked: cargo test -p g1t-work (189 passing).6e24edfHistory
README.md
GitHub's workflow schema
workflow-v1.0.json is GitHub's schema for workflow files, copied unchanged from
actions/languageservices, file
workflow-parser/src/workflow-v1.0.json, at commit
4043eda158e16579cc5fb1b0b07a4bce2a76f0b5 (5 August 2026). It is MIT licensed;
LICENSE is that repository's licence, copied from the same commit.
g1t does not read it at run time. src/syntax.rs lists the keys each part of a
workflow may have, and its tests check those lists against this file, so they
cannot drift from GitHub's. To update it, copy the file again, write the commit
here, and run cargo test -p g1t-actions.