Recurring rejected drift — antigravity engine catalog

The Daily Documentation Healer re-encountered the antigravity/pi built-in engine catalog drift via closed issue #44572 ([deep-report] Sync engine catalog: add pi and antigravity built-in engines to schema, docs, and code comments). Its fix PR was rejected again.

Rejection signal (verified)

• PR #44649 (Sync built-in engine catalog references for antigravity and pi, author Copilot) was closed unmerged by @pelikhan on 2026-07-10 (timeline closed event actor = pelikhan; collaborators/pelikhan/permission -> admin). No merge, no accepting review.
• This is the third rejection of the same docs/schema-only direction:
  1. PR Document Antigravity engine support in reference docs and schema guidance #42294 — closed unmerged by @pelikhan (2026-06-29)
  2. Escalation issue #42847 — auto-expired not_planned 2026-07-05 without a maintainer decision (A/B/C never answered)
  3. PR Sync built-in engine catalog references for antigravity and pi #44649 — closed unmerged by @pelikhan (2026-07-10)

Per healer rules, a closed-unmerged [docs] PR from a repo admin is a strong rejection signal. The healer will not re-attempt the engines.md / schema edit for antigravity.

Verified drift state on main (2026-07-12)

$ grep -ci antigravity docs/src/content/docs/reference/engines.md
0
$ grep -c antigravity pkg/parser/schemas/main_workflow_schema.json
0
$ grep -n 'NewAntigravityEngine' pkg/workflow/agentic_engine.go
494:		NewAntigravityEngine(),

Note: pi is already documented (engines.md: 9 mentions; schema description lists pi). The only recurring exclusion is antigravity, which is registered and used in production (.github/workflows/smoke-antigravity.md sets engine.id: antigravity) but deliberately kept out of the reference/schema. Nothing in code records this exclusion, so drift detectors (DeepReport / schema-consistency) keep re-filing the identical reconciliation request, and each cycle costs a healer/DDUw investigation to re-derive the same rejected conclusion.

Proposed inverse fix direction (code, not docs)

Since expanding docs/schema to include antigravity has been rejected three times, record the exclusion as intent so detectors stop flagging it:

1. Add an undocumented (or hidden) boolean to the engine's base config, defaulting false, set true in NewAntigravityEngine() (pkg/workflow/antigravity_engine.go).
2. Teach the DeepReport / schema-consistency drift checks that compare registered engines against engines listed in engines.md / main_workflow_schema.json to skip engines where undocumented == true.
3. No engines.md or schema change required — the exclusion becomes the documented, enforced expectation.

DDUw / healer improvement

DDUw does not detect that a drift issue's fix direction was already rejected before re-attempting the same edit. Add a pre-fix sub-step: for each candidate drift, search prior PRs touching the same file/keyword (is:pr is:closed is:unmerged, bot authors) closed by a repo collaborator; if found, treat the docs-only direction as rejected and escalate an inverse-fix decision instead of editing. This would have short-circuited the antigravity case directly and prevented the #44572 -> #44649 re-attempt.

Decision needed

@pelikhan — the earlier escalation (#42847) expired unanswered and the direction was then rejected a third time. Your call:

• Option A (default, per repeated rejection): land the undocumented: true marker + detector skip so antigravity/[deep-report] Sync engine catalog: add pi and antigravity built-in engines to schema, docs, and code comments #44572-class issues stop regenerating.
• Option B: the closes were accidental — antigravity should be documented; re-affirm and a docs/schema PR can be refiled.
• Option C: antigravity is internal/on its way out for a reason not captured here — say so and we'll scope accordingly.

Replying A/B/C is enough. Whichever path, it should drive a follow-up change rather than letting the drift regenerate every DeepReport cycle.

Other closed documentation issues reviewed this run

Content issues closed in the last 7 days — all already resolved by merged PRs, no gap:

• docs: self-hosted-runners reference reads DinD as optional for ARC — should state it's required #44569 (self-hosted-runners DinD) -> merged PR docs: DinD is required for ARC (not optional), fix NET_ADMIN misinformation, clarify sudo scope #44586
• Add a guide for running GitHub Copilot coding agent on ARC with DinD #44559 (ARC DinD Copilot guide) -> merged PR Add ARC DinD how-to guide for running GitHub Copilot coding agent on self-hosted runners #44561
• Spec: document sink-visibility field in MCP Gateway write-sink guard policy #44290 (MCP Gateway sink-visibility spec) -> merged PR docs: document sink-visibility field in MCP Gateway write-sink guard policy (spec v1.15.0) #44305
• [deep-report] Docs: define "frontmatter" and .lock.yml on first use in Quick Start #44059 (Quick Start frontmatter/.lock.yml terms) -> merged PR Clarify Quick Start terminology for frontmatter and .lock.yml #44079

The remaining documentation-labeled closures are automated recurring reports ([cli-consistency], [Daily Report], [spec-librarian], [deep-report] meta, multi-device testing) with no doc-content fix path.

Artifact constant audit

All ArtifactName constants in pkg/constants/ are either documented in docs/src/content/docs/reference/artifacts.md or not yet produced. New EvalsArtifactName = "evals" is conditionally produced only when a workflow declares evals (buildEvalsJob returns nil otherwise) and appears in no generated .lock.yml today — skipped as an unimplemented-in-practice surface, not a doc gap.

No site-build/UI issues encountered this run.

Generated by 📝 Daily Documentation Healer · 183.8 AIC · ⌖ 37.6 AIC · ⊞ 8K · ◷

• expires on Jul 14, 2026, 4:09 PM UTC-08:00