[SF-18] Harden verification architecture

[alexanderbrunker-star]

Ticket

• SF-18: https://linear.app/captain-leopard-ai-engineering/issue/SF-18/audit-and-resolve-all-warnings-in-github-prs-before-merge-enforce-zero

Summary

• add make test, make test-android, and make test-ios as shared verification entry points
• expand scripts/check_warnings.sh with warning-classifier self-tests plus Chrome, iOS simulator, and Android unit-test coverage
• update README/workflow docs with the new merge gates and keep the design/plan notes in docs/superpowers

Verification

• make test
• make verify

[linear]

SF-18 Audit and resolve all warnings in GitHub PRs before merge; enforce zero-warning standard

🧾 Description

All pull requests must be checked for warnings (lint, type, build, or code quality warnings) before being merged.

Codex should:

1. Analyze all warnings reported in the PR (via CI, CodeQL, linters, etc.)
2. Fix these warnings automatically where possible
3. Open a follow-up PR (or update the current PR) ensuring zero warnings

GitHub code quality tools already surface warnings directly in PRs and can suggest fixes or allow automated remediation via agents. 

---

🎯 Objectives

• Prevent accumulation of technical debt from warnings
• Ensure high code quality before merging
• Automate warning resolution via Codex

---

🛠 Scope of Work

1. PR Warning Detection

• Codex scans:
  • CI logs (GitHub Actions)
  • Lint results (ESLint, etc.)
  • CodeQL / security findings
• Extract:
  • Warnings
  • Severity (Error / Warning / Info)

👉 Warnings are typically visible in PR checks or comments generated by CI tools. 

---

2. Automated Fixing (Codex)

• Codex should:
  • Attempt auto-fixes (formatting, lint fixes, refactoring)
  • Apply suggested fixes from GitHub (if available)
• If applicable:
  • Use PR comment trigger (e.g. @codex fix warnings)

👉 GitHub supports automated fixes via agents that create PRs with corrections. 

---

3. PR Update / New PR Creation

• If fixes are minor → push to same PR
• If fixes are extensive → create new PR:
  • Title: fix: resolve warnings in <original PR>

---

4. CI Enforcement Rule

• Update CI pipeline:
  • Fail build if warnings exist (configurable)
• Option:
  • Treat warnings as errors

👉 Best practice: block merges when quality checks fail or warnings exceed threshold. 

---

5. Visibility Improvements (Optional)

• Add GitHub Action to:
  • Post warnings as PR comments
  • Highlight affected lines

👉 Tools exist that automatically comment warnings directly on PRs. 

---

✅ Acceptance Criteria

•  Codex scans every PR for warnings
•  All warnings are identified and listed
•  Codex fixes warnings automatically where possible
•  PR contains zero warnings before merge
•  CI fails if warnings remain
•  No regression in functionality

---

⚠️ Risks / Notes

• Some warnings may be false positives → allow explicit ignore rules
• Large legacy codebases may require gradual enforcement
• Avoid over-aggressive auto-fixes that change logic

---

📦 Deliverables

• Updated CI configuration (zero-warning enforcement)
• Codex automation workflow
• Clean PRs without warnings

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 77bf9717dc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Exclude ineligible simulators when choosing iOS test destination

find_ios_test_destination() currently treats any line containing platform:iOS Simulator as eligible, so it can select IDs from xcodebuild’s “Ineligible destinations” section (for example, simulators with missing runtimes). In that case run_ios_tests_if_available runs xcodebuild ... test with an unusable destination and fails, even though the intended behavior is to skip when no compatible simulator is available. Please filter out ineligible entries (e.g., lines with error: or by parsing only the “Available destinations” block) before assigning fallback.

Useful? React with 👍 / 👎.