[diegosouzapw]

Release-green pre-flight validator + nightly signal (Solutions C + D)

Implements the non-blocking half of the release-CI proposal you approved (C + D).

Problem

The full gate (ci.yml — unit shards, vitest, ratchets, package-artifact) runs only on the release PR (PR → main). PRs into release/** only get the fast-gates (quality.yml: TIA-impacted tests + typecheck + lint checks). So reds accrue silently on the release branch and explode in ~40-min layers at release time (this exact pattern cost 4 CI rounds on v3.8.33).

C — npm run check:release-green (scripts/quality/validate-release-green.mjs)

Reproduces the release-equivalent validation against the current working tree and classifies every red:

• HARD (real defect → exit 1): typecheck, eslint errors, db-rules, public-creds, full test:unit:ci, test:vitest, and check:pack-artifact (with --with-build).
• DRIFT (report-only, never affects exit code): eslint warnings, cognitive-complexity, file-size — each vs its committed quality-baseline.json.
• Flags: --json, --with-build, --quick. Pure helpers are exported + orchestration is behind a direct-run guard → unit-tested (tests/unit/validate-release-green.test.ts, 6 tests).

D — .github/workflows/nightly-release-green.yml

Runs C on the active release/vX.Y.Z nightly (+ workflow_dispatch) and opens/updates a single tracking issue on HARD failures. Not a required status check, never touches a contributor PR; ratchet drift is reported but never raises the alarm on its own. Branch name is format-guarded against ref/command injection.

Non-blocking by construction

This is maintainer tooling. Contributors are never blocked; drift is the maintainer's to rebaseline at release; real defects are fixed in the originating PR branch via co-authorship (the /review-prs Step 7 path). The on-demand /validate-release-green skill (local, not committed) wraps the script.

Validation

• New unit test: 6/6 pass.
• typecheck:core clean; eslint 0 errors; docs-sync pass; file-size OK (new files < cap); script self-run → RELEASE-GREEN exit 0.

Follow-ups (deferred — A/B/E, not in this PR)

• A: /green-prs on-demand skill (triage + fix-to-green across the open-PR queue).
• B: wire C into /review-prs Step 7/8 (verify-green-before-merge).
• E: call C in /generate-release Phase 0 (pre-flight so the release PR is green on the 1st run).

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request introduces a 'release-green' pre-flight validator script (validate-release-green.mjs) along with its unit tests and a new npm script in package.json to diagnose the state of the release branch. The review feedback highlights a violation of the Repository Style Guide regarding file placement, suggesting the script be moved to the scripts/check/ directory. Additionally, the reviewer points out Windows compatibility issues with executing npx via execFileSync, suggests making the ESLint JSON parsing more robust against leading bracket characters, and recommends improving error handling to capture system-level spawn errors.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

On Windows, npx (like npm) is a batch/cmd script and cannot be executed directly via execFileSync without appending .cmd (unless shell: true is used).

Defining npxCmd using the same platform check as npmCmd ensures cross-platform compatibility.

Suggested change

	const npmCmd = process.platform === "win32" ? "npm.cmd" : "npm";
	const npmCmd = process.platform === "win32" ? "npm.cmd" : "npm";
	const npxCmd = process.platform === "win32" ? "npx.cmd" : "npx";

[gemini-code-assist]

Use the platform-aware npxCmd instead of the hardcoded "npx" string to ensure the script runs successfully on Windows.

Suggested change

	const { out } = run("npx", ["eslint", ".", "--format", "json"]);
	const { out } = run(npxCmd, ["eslint", ".", "--format", "json"]);

[gemini-code-assist]

According to the Repository Style Guide (Section 1, Rule 8), all maintenance, debugging, generation, or experimental scripts must be placed strictly inside one of the following scripts/ subfolders: build/, dev/, check/, docs/, i18n/, or ad-hoc/.

The subfolder quality/ is not in the allowed list. Since this script is a validator/check, it should be placed under scripts/check/validate-release-green.mjs to adhere to the style guide.

References

1. ALL maintenance, debugging, generation, or experimental scripts MUST be placed strictly inside one of the scripts/ subfolders (build/, dev/, check/, docs/, i18n/, ad-hoc/). ^(link)

[gemini-code-assist]

If the command output contains any leading text with a [ character (for example, a package manager warning like [npm] warn ... or an ESLint loader message), indexOf("[") will match that first bracket instead of the actual JSON array. This will cause JSON.parse to fail and return null.

We can make this more robust by iteratively trying to parse from each [ found in the output until we successfully parse the JSON array or run out of brackets.

export function parseEslintJson(out) {
  const str = String(out || "");
  const start = str.indexOf("[");
  if (start < 0) return null;
  let idx = start;
  while (idx !== -1) {
    try {
      return JSON.parse(str.slice(idx));
    } catch {
      idx = str.indexOf("[", idx + 1);
    }
  }
  return null;
}

[gemini-code-assist]

If execFileSync fails due to a system error (e.g., ENOENT because npm or npx is not found in the PATH), the error object err will not contain stdout or stderr. In this case, out will be an empty string, completely hiding the root cause of the failure.

Falling back to err.message or String(err) ensures that spawn/system errors are visible in the output and easier to debug.

Suggested change

	} catch (err) {
	return {
	code: typeof err.status === "number" ? err.status : 1,
	out: `${err.stdout || ""}${err.stderr || ""}`,
	};
	}
	} catch (err) {
	return {
	code: typeof err.status === "number" ? err.status : 1,
	out: `${err.stdout || ""}${err.stderr || ""}` || err.message || String(err),
	};
	}

[gemini-code-assist]

If the script is moved to scripts/check/validate-release-green.mjs to comply with the Repository Style Guide, this script path should be updated accordingly.

Suggested change

	"check:release-green": "node scripts/quality/validate-release-green.mjs",
	"check:release-green": "node scripts/check/validate-release-green.mjs",

[gemini-code-assist]

If the script is moved to scripts/check/validate-release-green.mjs to comply with the Repository Style Guide, this import path should be updated accordingly.

const mod = await import("../../scripts/check/validate-release-green.mjs");