syntaqxThe docs say how the merge queue blames a failure: a state is held while entries ahead of it are still being tested, smaller combinations narrow down which entries ahead a change breaks with within three builds, who is told and with what (the timeline, the issue, the session, an integration_failure decision and integration.failed), and that a fixed pull request rejoins the queue by itself once its checks pass. Sessions and why-blame gains decision records (their kinds and confidences, what g1t records itself, record_decision and list_decisions) and why over the API; the webhooks guide lists integration.failed, integration.passed and decision.recorded; the MCP reference, bring your own agent and llms.txt name the new actions.b548a9aHistory
- ..
- about.rs
- archive_links.rs
- backups.rs
- blame.rs
- catch_up.rs
- coalesce.rs
- commit_file.rs
- contributors.rs
- copy.rs
- diff.rs
- drift.rs
- fallback.rs
- forks.rs
- git_http.rs
- git_ops.rs
- hidden_refs.rs
- import.rs
- land.rs
- languages.rs
- last_commits.rs
- lib.rs
- license.rs
- lifecycle.rs
- limits.rs
- listing.rs
- meters.rs
- moves.rs
- namespaces.rs
- pack_cache.rs
- pack_limits.rs
- push_checks.rs
- push_commits.rs
- refs.rs
- refs_cache.rs
- registry.rs
- resilience.rs
- rule_facts.rs
- rules.rs
- run_access.rs
- secret_scan.rs
- shards.rs
- shared.rs
- signatures.rs
- stats.rs
- store.rs
- test_merge.rs
- transfer.rs
- workflow_gate.rs