WA-VERIFY-068: Add CI invocation of verify-zeitwerk.sh to default-appraisal job

[kitcommerce]

Summary

Adds automated Zeitwerk autoload verification to CI pipeline.

Changes

• Added zeitwerk_verification job to CI workflow
• Job runs on Ruby 3.2 with default Gemfile (Rails 6.1)
• Starts Docker services (MongoDB, Redis, Elasticsearch)
• Invokes script/default_appraisal_zeitwerk_check
• Job fails on Zeitwerk autoload errors

Testing

• ✅ Confirmed script/default_appraisal_zeitwerk_check exists and is executable
• ✅ Script includes proper Docker service detection
• ✅ Job placement: after bundle install, before test jobs
• ✅ Uses Ruby 3.2 (stable CI target)

Client Impact

None — CI-only change. No changes to application code, APIs, or runtime behavior.

Related

Part of Zeitwerk migration verification — ensures autoload regressions are caught automatically on every PR.

[kitcommerce]

🔍 Wave 1 — Security Review — PR #1035

Verdict: ✅ PASS_WITH_NOTES (LOW)

CI-only change with no secrets, credentials, or user-facing code. No exploitable security issues.

Findings

Severity	File	Note
LOW	.github/workflows/ci.yml (L207)	GitHub Actions (actions/checkout@v4, ruby/setup-ruby@v1) are pinned to mutable major-version tags rather than immutable commit SHAs. A compromised tag could inject malicious code into CI. Consider pinning to full commit SHAs per OSSF/Scorecard best practices.

This is consistent with the supply-chain hardening already noted in PR #1020 — could be addressed as a follow-up across all workflows.

[kitcommerce]

🔍 Wave 2 — Deep-Dive Review — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS

Single-file CI workflow addition — adds a zeitwerk_verification job that:

1. Checks out code, sets up Ruby 3.2 with bundler cache
2. Installs docker-compose and ImageMagick
3. Starts Docker services (MongoDB, Redis, ES)
4. Runs script/default_appraisal_zeitwerk_check

No database schema changes, no application code changes, no migration impact. This is purely CI infrastructure.

Notes

• The script reference (script/default_appraisal_zeitwerk_check) should exist and be executable — PR description confirms this was verified.
• docker-compose up -d assumes a docker-compose.yml at repo root, which is consistent with other CI jobs in this workflow.
• No concerns with this change.

[kitcommerce]

🔍 Wave 3 — Performance Review — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS

CI-only change — no runtime performance impact on the application.

The new job adds ~2-5 min to total CI wall time but runs in parallel with other jobs, so it shouldn't meaningfully increase the CI feedback loop. The job uses bundler-cache: true which is good for caching gems across runs.

No concerns.

[kitcommerce]

🔍 Wave 4 — Documentation Review — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS

PR description clearly explains:

• What's being added (Zeitwerk autoload verification in CI)
• What it does (runs the verification script against Docker services)
• Testing confirmation (script exists, is executable, includes Docker service detection)
• Client impact: None (CI-only)

Job naming in the workflow ("Zeitwerk autoload verification") is descriptive and consistent with the existing job naming style.

No documentation concerns.

[kitcommerce]

🏗️ Architecture Notes — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS_WITH_NOTES (LOW)

Clean, self-contained CI job addition. No architectural violations — properly isolated with no coupling to other workflow jobs. Three minor observations:

1. CI setup duplication (LOW): The job duplicates infrastructure setup (checkout, ruby/setup-ruby, docker-compose, apt-get) found in other CI jobs. If duplication grows, consider extracting into a reusable composite action (.github/actions/setup-ruby-services/action.yml).

2. Script naming (LOW): Issue acceptance criteria references scripts/verify-zeitwerk.sh but the job invokes script/default_appraisal_zeitwerk_check. The indirection is fine but a brief clarifying note in the PR or workflow comment would help future maintainers.

3. Branch protection (LOW): The job has no needs: clause (correct — it should run independently), but verify that branch protection rules include zeitwerk_verification as a required status check so failures actually block merges.

[kitcommerce]

🪶 Simplicity Review — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS_WITH_NOTES (LOW)

The job is minimal and proportional — no over-engineering. One observation worth checking:

Potentially unnecessary dependencies (LOW): The job installs docker-compose + imagemagick and starts Docker services before running the Zeitwerk check. Zeitwerk autoload verification is typically a pure Ruby constant-resolution check at Rails boot — it shouldn't require live backing services (MongoDB, Redis, ES) or ImageMagick.

Question: Does script/default_appraisal_zeitwerk_check actually need running services? If not, those steps may be cargo-culted from another CI job and can be dropped. A leaner Zeitwerk-only job (checkout → setup-ruby → bundle install → run check) would be faster and more self-documenting.

[kitcommerce]

🛤️ Rails Conventions Review — PR #1035 (Zeitwerk CI Verification)

Verdict: ✅ PASS_WITH_NOTES (LOW)

CI-only change, no application code affected. Two minor convention issues worth addressing:

Findings

1. docker-compose v1 deprecation (LOW): The job installs docker-compose via apt (the legacy standalone v1 tool) and calls docker-compose up -d. Docker Compose v1 is deprecated and being removed from apt repos. ubuntu-latest already ships with the Compose v2 plugin.

   • Fix: Remove docker-compose from apt install. Replace docker-compose up -d with docker compose up -d (no hyphen, v2 plugin).

2. Hardcoded Ruby version (LOW): ruby-version: 3.2 is hardcoded. Rails convention is to use a .ruby-version file — ruby/setup-ruby@v1 reads it automatically if ruby-version: is omitted. This avoids silent divergence when the project-wide Ruby version is updated.

   • Fix: Omit ruby-version: entirely, or set ruby-version: .ruby-version to be explicit.

[kitcommerce]

🏗️ Architecture Review (Wave 1)

Verdict: PASS_WITH_NOTES (LOW)

Clean, self-contained CI job addition. No architectural violations — the job is properly isolated with no coupling to other workflow jobs.

Finding 1 (LOW): New zeitwerk_verification job duplicates infrastructure setup (checkout, ruby/setup-ruby, docker-compose, apt-get) present in other CI jobs. No composite action used — creates maintenance surface.

Finding 2 (LOW): The job invokes script/default_appraisal_zeitwerk_check but the issue acceptance criteria reference scripts/verify-zeitwerk.sh. The naming inconsistency could cause confusion during future maintenance.

Finding 3 (LOW): No needs: clause means the job runs in parallel — architecturally correct — but verify that branch protection rules include zeitwerk_verification as a required status check so failures actually block merges.

[kitcommerce]

✨ Simplicity Review (Wave 1)

Verdict: PASS_WITH_NOTES (LOW)

The CI job is minimal and proportional — no over-engineering or unnecessary abstraction.

Finding (LOW): The job installs docker-compose + imagemagick and spins up services before what is described as a Zeitwerk autoload verification. Zeitwerk checks are typically pure Ruby boot-time — they should not require live backing services or image processing. Confirm whether these deps are genuinely required by the script; if not, they are unnecessary weight.

[kitcommerce]

🔒 Security Review (Wave 1)

Verdict: PASS_WITH_NOTES (LOW)

CI-only change — no secrets, credentials, or user-facing code. No exploitable issues.

Finding (LOW): actions/checkout@v4 and ruby/setup-ruby@v1 are pinned to mutable major-version tags rather than immutable commit SHAs. A compromised tag could inject malicious code into CI.

Suggestion: Pin to full commit SHAs for supply-chain hardening (consistent with OSSF/Scorecard). Not urgent if the rest of the workflow already uses tag pinning.

[kitcommerce]

Performance Review

{
  "reviewer": "performance",
  "verdict": "PASS",
  "severity": null,
  "summary": "CI-only YAML change adds a new GitHub Actions job; no application code paths, algorithms, memory allocations, or I/O patterns are affected.",
  "findings": []
}

No performance concerns. This change is entirely within CI infrastructure — it adds a new workflow job that installs system dependencies, starts Docker services, and runs a shell script. None of this touches application hot paths, query patterns, memory allocation, or runtime execution. The apt-get update && apt-get install is expected CI overhead and does not affect application performance.

[kitcommerce]

Frontend Review

{
  "reviewer": "frontend",
  "verdict": "PASS",
  "severity": null,
  "summary": "CI-only YAML change with no JavaScript, TypeScript, Stimulus controllers, Turbo/Hotwire patterns, or asset pipeline modifications.",
  "findings": []
}

No frontend concerns. The diff is exclusively a GitHub Actions workflow job definition. There are no changes to Stimulus controllers, Turbo Frames/Streams, JavaScript assets, import maps, or form behavior. Nothing in this change affects the browser-side stack.

[kitcommerce]

Accessibility Review

{
  "reviewer": "accessibility",
  "verdict": "PASS",
  "severity": null,
  "summary": "CI-only YAML change introduces no user-facing UI; no accessibility concerns apply.",
  "findings": []
}

No accessibility concerns. This change adds a GitHub Actions workflow job for Zeitwerk autoload verification. There are no user-facing views, interactive controls, color usage, Dynamic Type considerations, or assistive technology touch points introduced or modified.

[kitcommerce]

Wave 4 (Documentation) Review

Verdict: PASS_WITH_NOTES (non-blocking)

What looks good

• Job name is clear and user-facing: Zeitwerk autoload verification.
• PR description explains why this is needed (catch autoload regressions automatically).
• PR body references the invoked script: .
• Client Impact section present and explicit (None — CI-only).

Notes / small improvements (optional)

• In , the step uses .
  Consider adding (or a short health/wait) if service readiness becomes flaky in CI.
  Not required if current scripts already handle readiness.

[kitcommerce]

@-

[kitcommerce]

@-