No CI at all: both workflows are checked in as *.disabled, so every vimcode PR is blocked by the merge gate with 'no checks reported'

[JDonaghy]

Symptom

coord merge refuses every vimcode PR, permanently:

vimcode #611 (issue-611-...): checks_failed — checks failed: coord: could not read
CI status for JDonaghy/vimcode#612 (gh pr checks failed: no checks reported on the
'issue-611-worktree-agents-cannot-query-the-graphif' branch) (unknown)

gh api repos/JDonaghy/vimcode/actions/workflows returns an empty list. The repo has no
active workflows at all, so no PR has ever reported a check.

Root cause: the workflows are checked in disabled

.github/workflows/ci.yml.disabled       (3.5K)
.github/workflows/release.yml.disabled  (11K)

Both were renamed to .disabled on 2026-04-30. GitHub only picks up .yml/.yaml, so they are
inert. The on: block in ci.yml.disabled is already correct for this repo
(branches: [main, develop]) — the file simply never runs.

Why it matters

coord's merge gate (#240) refuses to merge when it cannot read a CI verdict. That is correct —
"no checks" means "no evidence this code works". Overriding with --force-merge on every
vimcode PR disables the gate repo-wide by habit. The repo needs a green gate, not a
comprehensive one.

Fix — re-enable a minimal job that is reliably green

Do not re-enable ci.yml.disabled wholesale. It defines four jobs, and three of them are
liabilities for a merge gate:

job	verdict
test (ubuntu-24.04, GTK4)	re-enable — this is the gate
build-macos (macos-latest)	leave disabled — paid runner minutes, slow, not required to merge
build-windows	leave disabled — vimcode is not shipped on Windows today (see docs/CROSS_PLATFORM.md M2, unstarted)
coverage (llvm-cov + Codecov)	leave disabled — needs a Codecov token this repo does not have

Rename ci.yml.disabled → ci.yml and reduce it to the Linux test job. Keep the existing
on: block unchanged — it is already [main, develop], which is what this repo needs.

Anchor the test command to what the Test stage already runs

coordinator.yml configures vimcode's test command as:

cargo test --no-default-features

That is the headless path — vimcode's default = ["gui"] feature pulls in GTK4, and
--no-default-features is what the fleet's Test stage has been running successfully all along.
CI should run the same command, so the merge gate and the Test stage cannot disagree about
whether the same commit passes. The disabled file's cargo test --verbose (default features,
GTK) is a different, unproven-in-CI command.

Suggested job shape — keep the existing caching and toolchain steps, change only what runs:

• cargo fmt -- --check
• cargo clippy --no-default-features -- -D warnings
• cargo build --no-default-features
• cargo test --no-default-features

Keeping GTK4 out of the job removes the libgtk-4-dev apt install entirely, which also makes it
substantially faster.

If fmt or clippy -D warnings fails on the current tree, do not silently drop the step and
do not mass-reformat the codebase to make it pass. Report what fails in the PR and ship the
build+test steps green; a follow-up issue can clean up the lint debt. A gate that runs is worth
more than a gate that is comprehensive.

Acceptance

This change verifies itself. For same-repo pull_request events GitHub evaluates the
workflow from the PR branch, so the PR that renames the file will itself receive checks.

• gh pr checks <this PR> must report the job, not "no checks reported".
• The job must be green. This is the whole point of the issue — a red gate blocks the merge
  queue exactly as hard as an absent one.
• cargo test --no-default-features must pass locally in the worktree before pushing. Verify by
  exit code, not by reading output.

Scope

• .github/workflows/ci.yml (renamed from ci.yml.disabled) only.

• Leave release.yml.disabled alone — releases are out of scope and re-enabling it could
  publish something.

• Do not change Cargo.toml, features, or any source file to make CI pass. If the code does not
  build under --no-default-features, that is a finding to report, not to patch here.
  AMENDED 2026-07-31 (operator decision, user-approved) — this constraint is unsatisfiable and is
  formally waived for the #615 snapshot fix and a comment-only Cargo.toml edit.

  ci.yml declares on: pull_request: branches: [main, develop], and that filter applies to the
  base branch. Consequences, all verified rather than assumed:

  1. No CI at all: both workflows are checked in as *.disabled, so every vimcode PR is blocked by the merge gate with 'no checks reported' #613 alone is RED — on exactly the six render snapshots that Six render snapshot tests pass locally and fail in CI: nerd-font glyph widths resolve differently, so the Test stage has been reporting green on machine-dependent assertions #615 fixes.
  2. Six render snapshot tests pass locally and fail in CI: nerd-font glyph widths resolve differently, so the Test stage has been reporting green on machine-dependent assertions #615's own PR (#615: Six render snapshot tests pass locally and fail in CI: nerd-font glyph widths resolve differently, so the Test stage has been reporting green on machine-dependent assertions #616) got zero checks: it branched before CI existed, and the merge gate
     refuses no checks reported.
  3. A stacked PR based on this branch also gets zero checks, because its base would not be
     main/develop.

  That is a deadlock. The only route to a CI-validated merge without --force-merge is for the
  snapshot fix to ride the branch that enables CI. Splitting and stacking were both evaluated and
  provably do not work — reviewers should not recommend either.

  The waived edits are narrow: the Cargo.toml change is comment-only (documenting the new
  quadraui clone step — verify with git diff), and the src/ change is 17 lines, test-only,
  inside #[cfg(test)] mod tests, independently approved by review e8347dcd91d0
  (approve, 0 blocking, 0 non-blocking). CI is green at d4682ce.

• Do not bump versions. Do not edit README*, CLAUDE.md, or docs/**.

Note

quadraui has the same symptom from a different cause — its ci.yml is active but only triggers
on PRs to main while the default branch is develop. Tracked separately in quadraui#514.

[JDonaghy]

Coordinator Assignment

Machine: elitebook
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #613: No CI at all: both workflows are checked in as *.disabled, so every vimcode PR is blocked by the merge gate with 'no checks reported'

Symptom

coord merge refuses every vimcode PR, permanently:

vimcode #611 (issue-611-...): checks_failed — checks failed: coord: could not read
CI status for JDonaghy/vimcode#612 (gh pr checks failed: no checks reported on the
'issue-611-worktree-agents-cannot-query-the-graphif' branch) (unknown)

gh api repos/JDonaghy/vimcode/actions/workflows returns an empty list. The repo has no
active workflows at all, so no PR has ever reported a check.

Root cause: the workflows are checked in disabled

.github/workflows/ci.yml.disabled       (3.5K)
.github/workflows/release.yml.disabled  (11K)

Both were renamed to .disabled on 2026-04-30. GitHub only picks up .yml/.yaml, so they are
inert. The on: block in ci.yml.disabled is already correct for this repo
(branches: [main, develop]) — the file simply never runs.

Why it matters

coord's merge gate (#240) refuses to merge when it cannot read a CI verdict. That is correct —
"no checks" means "no evidence this code works". Overriding with --force-merge on every
vimcode PR disables the gate repo-wide by habit. The repo needs a green gate, not a
comprehensive one.

Fix — re-enable a minimal job that is reliably green

Do not re-enable ci.yml.disabled wholesale. It defines four jobs, and three of them are
liabilities for a merge gate:

job	verdict
test (ubuntu-24.04, GTK4)	re-enable — this is the gate
build-macos (macos-latest)	leave disabled — paid runner minutes, slow, not required to merge
build-windows	leave disabled — vimcode is not shipped on Windows today (see docs/CROSS_PLATFORM.md M2, unstarted)
coverage (llvm-cov + Codecov)	leave disabled — needs a Codecov token this repo does not have

Rename ci.yml.disabled → ci.yml and reduce it to the Linux test job. Keep the existing
on: block unchanged — it is already [main, develop], which is what this repo needs.

Anchor the test command to what the Test stage already runs

coordinator.yml configures vimcode's test command as:

cargo test --no-default-features

That is the headless path — vimcode's default = ["gui"] feature pulls in GTK4, and
--no-default-features is what the fleet's Test stage has been running successfully all along.
CI should run the same command, so the merge gate and the Test stage cannot disagree about
whether the same commit passes. The disabled file's cargo test --verbose (default features,
GTK) is a different, unproven-in-CI command.

Suggested job shape — keep the existing caching and toolchain steps, change only what runs:

• cargo fmt -- --check
• cargo clippy --no-default-features -- -D warnings
• cargo build --no-default-features
• cargo test --no-default-features

Keeping GTK4 out of the job removes the libgtk-4-dev apt install entirely, which also makes it
substantially faster.

If fmt or clippy -D warnings fails on the current tree, do not silently drop the step and
do not mass-reformat the codebase to make it pass. Report what fails in the PR and ship the
build+test steps green; a follow-up issue can clean up the lint debt. A gate that runs is worth
more than a gate that is comprehensive.

Acceptance

This change verifies itself. For same-repo pull_request events GitHub evaluates the
workflow from the PR branch, so the PR that renames the file will itself receive checks.

• gh pr checks <this PR> must report the job, not "no checks reported".
• The job must be green. This is the whole point of the issue — a red gate blocks the merge
  queue exactly as hard as an absent one.
• cargo test --no-default-features must pass locally in the worktree before pushing. Verify by
  exit code, not by reading output.

Scope

• .github/workflows/ci.yml (renamed from ci.yml.disabled) only.
• Leave release.yml.disabled alone — releases are out of scope and re-enabling it could
  publish something.
• Do not change Cargo.toml, features, or any source file to make CI pass. If the code does not
  build under --no-default-features, that is a finding to report, not to patch here.
• Do not bump versions. Do not edit README*, CLAUDE.md, or docs/**.

Note

quadraui has the same symptom from a different cause — its ci.yml is active but only triggers
on PRs to main while the default branch is develop. Tracked separately in quadraui#514.

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: 6m 16s
Log: /home/john/.coord/logs/5c4c4be9e32e.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: 6m 9s
Log: /home/john/.coord/logs/c71a60d18288.log

[JDonaghy]

Review Complete — ✅ Approved

Reviewer findings could not be posted directly to PR #614 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Summary

Reviewed the merge-base diff for PR #614 against issue #613's detailed spec, and cross-checked the actual pushed branch (origin/issue-613-no-ci-at-all-both-workflows-are-checked) to confirm the diff shown matches what's really on the remote.

Findings:

• ci.yml.disabled (147 lines, 4 jobs) is deleted and replaced by a new ci.yml (51 lines, 1 job) — exactly the "rename + shrink to the Linux test job" instruction in the issue.
• on: block (push/pull_request on [main, develop]) is preserved verbatim, as required.
• The three jobs the issue says to leave disabled (build-macos, build-windows, coverage) are gone entirely, not just commented out.
• GTK4 apt install step (libgtk-4-dev) is removed, consistent with dropping GUI-feature builds.
• Steps now run cargo fmt -- --check, cargo clippy --no-default-features -- -D warnings, cargo build --no-default-features, cargo test --no-default-features — matches the issue's suggested shape exactly, and matches coordinator.yml's Test-stage command so the gate and Test stage can't disagree.
• Caching steps (registry/index/build) are carried over unchanged from the disabled file.
• git diff origin/develop...HEAD -- .github/workflows/release.yml.disabled is empty — confirmed untouched, in scope.
• No Cargo.toml, source, or doc files touched — diffstat is exactly the two workflow files, nothing else.
• The commit message records local verification with exit-code checks for all four commands (fmt --check, clippy -D warnings, build, test — "44 test binaries, 0 failures"), satisfying the issue's "verify by exit code, not by reading output" requirement and confirming fmt/clippy didn't need to be silently dropped.

I did not run cargo build/test/clippy myself per this review's instructions (Test-stage/build-verification is a separate pipeline step), and I did not run any gh commands, so I can't independently confirm the live GitHub Actions run on PR #614 came back green — see non-blocking note below.

Blocking findings

None.

Non-blocking concerns

• I could not independently confirm via gh pr checks 614 that the job actually reported and went green on GitHub (I'm barred from running gh in this review). Since this change is explicitly self-verifying (the PR's own branch triggers the new workflow), the coordinator should confirm gh pr checks 614 shows a green test job — not "no checks reported" — before merging, per the issue's acceptance criteria.

Nits

None.

[JDonaghy]

Review Complete — ⚠️ Changes Requested

Reviewer findings could not be posted directly to PR #614 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Blocking findings

• Scope violation: source file and Cargo.toml changes outside the stated ".github/workflows/ci.yml only" scope. The issue is explicit and repeats itself: "Do not change Cargo.toml, features, or any source file to make CI pass. If the code does not build under --no-default-features, that is a finding to report, not to patch here." This PR does both:

  • src/tui_main/render_impl.rs (test helper test_engine) is modified to make the sidebar-visibility state hermetic, fixing a real bug where CI's fresh $HOME produces explorer_visible: false and desyncs from committed snapshots. The fix itself looks correct and follows the existing precedent for the identical problem class already in the same function (the #439 git-branch/ahead/behind reset a few lines above), but it is a substantive behavior fix for a different, separately tracked issue (#615), whose commit history on this branch (d4682ce, 3a4fc3f, 95ae854, 184d199, 2ca07c4) shows several abandoned diagnostic/revert attempts before landing here. Bundling that exploration into the CI-enablement PR is exactly the kind of coupling the issue's scope section tried to prevent — it should land as its own PR against #615 (which appears to already exist, going by the comment/commit references), with this PR either depending on it or reporting "test X fails hermetically in a fresh environment" as a finding per the issue's own prescribed process for build failures.
  • Cargo.toml's comment block is rewritten to describe the new CI clone step and the develop-pinning risk. Comment-only and low-risk, but still an edit to a file the issue explicitly named as off-limits ("only" ci.yml).

  Given the issue's carve-out logic for build failures ("report, don't patch... a gate that runs is worth more than a gate that is comprehensive") implies the same standard applies to test failures, this should have been reported rather than fixed inline, or explicitly called out and approved as a deliberate, disclosed exception in the PR description.

Non-blocking concerns

• The new ci.yml adds a git clone --depth 1 --branch develop https://github.com/JDonaghy/quadraui.git step that the original ci.yml.disabled never had (the disabled file predates the Session 346 quadraui extraction, so it likely never would have built as-is). This is a genuine improvement and appears path-correct (../quadraui/quadraui relative to $GITHUB_WORKSPACE matches dirname("$GITHUB_WORKSPACE")/quadraui as the clone target), but it means vimcode's merge gate is now transitively dependent on quadraui's develop HEAD being green. The Cargo.toml comment honestly discloses this ("a breaking change there turns vimcode CI red without vimcode changing"), which is good, but it's worth the team being aware this is a new failure mode for the gate that didn't exist before (previously: no gate at all).
• No visibility from the diff alone into whether cargo fmt -- --check / cargo clippy --no-default-features -- -D warnings actually pass on the current tree — the issue anticipated this might fail and asked that failures be reported rather than silently patched/reformatted. Worth confirming the first actual CI run on this PR is green (per the issue's own self-verifying acceptance criterion) before merging, and that if either step is red, it was reported rather than papered over.

Nits

• The Cargo.toml comment now says "CI must clone quadraui as a sibling before any cargo step... see the 'Check out quadraui' step in .github/workflows/ci.yml" — accurate and helpful, just flagging again that it's a scope-adjacent edit (see blocking finding) rather than a defect in the text itself.

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: 21m 49s