Review workflow: GPT Review fails before review when credential is absent

[100yenadmin]

Summary

The active 🤖 GPT Review workflow can be dispatched successfully but fails before producing any review when its API credential is not configured.

Observed on PR #676:

• workflow run: https://github.com/100yenadmin/evaOS-GUI/actions/runs/29239317436
• diff gathering, changed-file reading, and prompt construction passed
• the provider-call step failed immediately because the required credential was unavailable
• no PR review or inline comment was produced

Impact

The workflow appears available but provides no adversarial review evidence. Release managers must detect the failure explicitly and use a named exact-head substitute reviewer; treating the run as a completed reviewer would weaken the review gate.

Expected behavior

Choose and document one fail-closed contract:

1. configure the approved repository/environment credential and add a credential preflight with a clear operator error; or
2. disable/remove the workflow until it is intentionally provisioned, so it cannot be mistaken for an available required reviewer.

The repair must not print, persist, or copy credential material. It should also ensure a manual PR-number review checks out or fetches the PR head, because workflow-run metadata may otherwise reflect the dispatch branch rather than the reviewed commit.

Acceptance proof

• a test PR at a named head SHA receives a completed review tied to that same SHA; or
• the workflow is explicitly disabled and release/review runbooks name the approved substitute-review route
• failure logs and PR comments contain no secret material

Parent tracker: #623.

[coderabbitai]

🔗 Related PRs

#375 - Expose Workbench functional smoke workflow on default branch [merged]
#377 - Pass bridge source token to Workbench smoke build [merged]
#399 - Register local signed DMG manifest workflow [merged]
#497 - [codex] Guard public repo sensitive content [merged]
#636 - fix(evaos): enforce no-ACP release packaging [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #678 - Review workflow: GPT Review fails before review when credential is absent
State: open; milestone: Workbench Runtime Reliability Release Train

Related issues/PRs: #676, #623.
Existing labels: bug, evaos, public-beta, ready-for-agent, area:release, kind:integration, blocked, release-train:runtime-reliability.
Suggested labels: security, docs, tests.
Suggested owners: none.

Related context

• fix(release): keep Python inventory stable through packaging #676 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Roadmap: Workbench runtime reliability release train #623 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: Review workflow: GPT Review fails before review when credential is absent - ## Summary The active 🤖 GPT Review workflow can be dispatched successfully but fails before producing any review when its API credential is not configured. Observed on PR #676: - workflow run:
Product fit: Architecture/integration issue; check repo policy, prior decisions, and operational constraints before implementation.
Implementation wedge: Start with a bounded adapter/contract or dry-run packet before changing live runtime behavior.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: deferred; no product, architecture, UX, library-choice, integration, roadmap, or market-positioning trigger detected.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• Contract or degraded-mode proof before runtime promotion.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [deferred] allowlisted_cross_repo_github: Deferred until product, UX, market-positioning, or library-choice signal appears.
• [deferred] external_oss_examples: Deferred for low-research-value issue class.
• [deferred] library_api_docs: Deferred unless a library/API decision is present.
• [deferred] current_market_examples: Deferred for implementation-only issues.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• No obvious issue triage gap detected from issue metadata.

No labels, owners, reviewers, or roadmap fields were changed by this bot.