syntaqxA merge queue entry that fails with nothing ahead of it, though its own checks pass on its head, is told what landed on the default branch since it branched: g1t looks at the 50 pull requests most recently merged into the default branch before the entry was tested, keeps those whose landed commits the entry's own history (its latest 1,000 commits, read from the repos service's log) does not hold, and reports up to ten, newest first, as `landed` on the integration.failed event, in the integration_failure decision's evidence (and so get_work's last_integration_failure), and in the notes on the pull request, its issue and its sessions: "fails on the default branch as it is now ... Since this branched, #1 landed and is the likely cause", or with several, that they may be what it conflicts with. The entry still answers for the failure and nothing is bisected; with nothing found the note says the change is the cause, as before, and conflicts, missing checks and builds never look it up. The contracts carry `landed` (Rust, defaulting to empty for older events, and the TypeScript mirror), the CLI's event line shows it, and the merge queue, webhooks and sessions guides, the API examples and the fix-integration skill say what it means.fae8c33History
- ..
- about.rs
- addresses.rs
- alerts.rs
- archives.rs
- audit.rs
- billing.rs
- blobs.rs
- broker.rs
- checks.rs
- coordination.rs
- deploy_keys.rs
- deployments.rs
- folios.rs
- follow.rs
- lib.rs
- limits.rs
- logs.rs
- mcp.rs
- notifications.rs
- oauth.rs
- oidc.rs
- openapi.rs
- operations.rs
- packages.rs
- people.rs
- pins.rs
- projects.rs
- protection.rs
- reference.json
- renamed.rs
- responses.rs
- rest.rs
- rules.rs
- run_artifacts.rs
- runners.rs
- security.rs
- telemetry.rs
- token_policy.rs
- toolkit.rs
- tools.rs
- why.rs