[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

[alexanderbrunker-star]

Closing in favor of #30, which uses the repo-required feature/SF-18 branch and PR title/body format.