WA-FORWARD-004: Move Ruby 3.4 stdlib gem deps from Gemfile to gemspec

[kitcommerce]

Summary

Moves the 5 Ruby 3.4 stdlib gems from being a Gemfile-level workaround to proper add_dependency entries in core/workarea-core.gemspec.

Closes #780

---

Changes

core/workarea-core.gemspec — added 5 add_dependency entries:

• mutex_m — extracted from stdlib in Ruby 3.4
• csv — extracted from stdlib in Ruby 3.4
• drb — extracted from stdlib in Ruby 3.4
• logger — extracted from stdlib in Ruby 3.4
• ostruct — extracted from stdlib in Ruby 3.4

Gemfile.lock — regenerated to reflect new resolved gems.

Root Gemfile — no change needed on this branch. The 5 stdlib gems were introduced as a workaround in PR #778's branch (not yet merged to next). This PR establishes the correct long-term home; when #778 merges its Gemfile entries should be dropped in favour of these gemspec-level declarations.

---

Why gemspec, not Gemfile

The root Gemfile is only used for the monorepo dev environment. Downstream implementations install workarea-core as a gem and inherit its gemspec dependencies — not its Gemfile. Declaring stdlib deps in the gemspec ensures any consumer using Ruby 3.4 gets them automatically without needing to modify their own Gemfile.

---

Verification

# Ruby 3.2.7 (local env)
bundle install
# → Bundle complete! 11 Gemfile dependencies, 221 gems now installed.

---

Client Impact

None expected. Downstream implementations using Ruby < 3.4 are unaffected (gems exist but stdlib already provides them). Implementations using Ruby 3.4 benefit automatically — no changes required on their end.

[kitcommerce]

Architecture Review

Verdict: PASS

Assessment

This change correctly moves Ruby 3.4 stdlib gem dependencies from a Gemfile-level workaround to proper add_dependency entries in workarea-core.gemspec. This is the architecturally correct location for these declarations.

Why this matters: When workarea-core is consumed as a gem dependency (not path-referenced), only gemspec dependencies propagate to downstream implementations. Gemfile entries are local to the source repo. Declaring these in the gemspec ensures all consumers automatically inherit the required stdlib gems regardless of their Ruby version.

Findings

• Dependency direction is correct. The gemspec is the public contract for gem consumers; the Gemfile is for local development. Moving deps from Gemfile → gemspec aligns with Bundler's dependency resolution architecture.
• No version constraints specified. The five add_dependency entries have no version pinning (e.g., ~> 3.0). This is acceptable here — these are Ruby stdlib extractions that maintain backward compatibility by design, and pinning would create unnecessary maintenance burden. Bundler will resolve to the latest compatible version.
• Comment block is well-placed. The explanatory comment above the new dependencies clearly communicates intent and rationale, reducing future maintenance confusion.
• Gemfile.lock regenerated correctly. The lock file reflects the new gemspec dependencies in the PATH section, confirming the resolution is consistent.
• No architectural boundaries violated. The change is scoped entirely to dependency declaration — no code changes, no new coupling, no behavioral impact.

Recommendations

None. This is a clean, minimal change that follows Ruby gem packaging conventions correctly.

[kitcommerce]

Simplicity Review

Verdict: PASS

Findings

• The change is mechanical and well-scoped: 5 add_dependency lines added to an existing block in workarea-core.gemspec, following the exact pattern already used throughout the file.
• The comment block above the new entries clearly explains the rationale (Ruby 3.4 extracted these from stdlib), removing any ambiguity for future readers.
• No new abstractions, no new configuration layers, no cleverness — just dependency declarations in their correct home.
• Gemfile.lock changes are expected mechanical output of bundle install after the gemspec update.

Recommendations

• Minor: The acceptance criteria for issue WA-FORWARD-004: Move Ruby 3.4 stdlib gem deps from Gemfile to gemspec #780 includes "Root Gemfile entries removed (or consolidated)." The PR description states the root Gemfile needed no change on this branch. Worth confirming whether the stdlib gems still appear in the root Gemfile (making them declared in two places) or were previously only in the Gemfile as a workaround and are now solely in the gemspec. If duplicated, a follow-up cleanup is low priority but would reduce noise.
• No simplicity concerns with the change as implemented.

[kitcommerce]

Security Review

Verdict: PASS

Findings

No security issues identified. This PR contains only dependency metadata changes:

1. No code changes — only workarea-core.gemspec (dependency declarations) and Gemfile.lock (regenerated) were modified. No .rb files touched.
2. No secrets or credentials — no API keys, tokens, or sensitive data introduced.
3. Dependencies are trusted — all 5 gems (mutex_m, csv, drb, logger, ostruct) are official Ruby stdlib extractions maintained by the Ruby core team. They were already present as bundled stdlib; this just makes them explicit for Ruby 3.4+.
4. No new attack surface — drb (Distributed Ruby) is notable as it can open network services, but it was already an implicit dependency via stdlib. Making it explicit in the gemspec doesn't change the threat model.

Notes

• The 5 dependencies are declared without version constraints (s.add_dependency 'csv' rather than s.add_dependency 'csv', '~> 3.0'). This is acceptable for stdlib extractions where the gem tracks the Ruby version, but pinning to a minimum version would add defense-in-depth against hypothetical supply-chain attacks on these gem names. Low priority, not blocking.

Recommendation

✅ Safe to merge from a security perspective.

[kitcommerce]

Rails Conventions Review\n\nVerdict: PASS\n\nCorrect Rails engine pattern: declare Ruby 3.4+ stdlib-extracted gems as runtime deps in so downstream apps inherit them. Notes only (non-blocking): consider future audit of existing usage; suggests legacy usage.\n

[kitcommerce]

Rails Conventions Review

Verdict: PASS

Correct Rails engine pattern: declare Ruby 3.4+ stdlib-extracted gems as runtime deps in core/workarea-core.gemspec so downstream apps inherit them.

Notes only (non-blocking): consider a future audit of existing OpenStruct usage; drb inclusion suggests legacy usage.

[kitcommerce]

Test Quality Review\n\nVerdict: PASS\n\nThis PR is dependency packaging only: it moves Ruby 3.4 stdlib-extracted gems (csv/drb/logger/mutex_m/ostruct) into the gemspec and updates . No application code or tests are modified.\n\nNotes (informational):\n- CI is green across the full matrix, including Ruby 3.4 bundle check.\n- No new test coverage is needed for this change.\n

[kitcommerce]

Test Quality Review (follow-up)

Verdict: PASS

This PR is dependency packaging only: it moves Ruby 3.4 stdlib-extracted gems (csv/drb/logger/mutex_m/ostruct) into the workarea-core gemspec and updates Gemfile.lock. No application code or tests are modified.

Notes (informational):

• CI is green across the full matrix, including Ruby 3.4 bundle check.
• No new test coverage is needed for this change.

[kitcommerce]

Wave 3 (Quality) — Manual dispatcher review

• Performance: PASS (dependency declaration only; no runtime hot paths changed)
• Frontend: PASS (no UI/templates/assets changes)
• Accessibility: PASS (no user-facing UI changes)

No further action required.

[kitcommerce]

Wave 4 (Documentation) — Manual dispatcher review (informational)

PR description is clear and includes client impact. No additional docs required. PASS_WITH_NOTES: optional CHANGELOG entry once this ships in a release.