Enhance contribution guidelines and add licensing FAQ for monorepo tr…

[AbanoubGhadban]

…ansition

Summary

Remove this paragraph and provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.

Pull Request checklist

Remove this line after checking all the items here. If the item is not applicable to the PR, both check it out and wrap it by ~.

• Add/update test to cover these changes
• Update documentation
• Update CHANGELOG file

Add the CHANGELOG entry at the top of the file.

Other Information

Remove this paragraph and mention any other important and relevant information such as benchmarks.

---

This change is 

Summary by CodeRabbit

• Documentation
  • Announced an in-progress monorepo merger with contributor transition guidance.
  • Added a licensing overview covering dual licensing (MIT and Pro), directory boundaries, developer guidelines, and CI-based compliance checks.
  • Added a licensing FAQ with practical examples for usage, installation, releases, rollback, and verification across merger phases.
  • Published a merger plan reference with a 7-phase roadmap, package identities, history preservation, and current Phase 1 status (date updated).
  • No changes to runtime behavior or public APIs.

[coderabbitai]

Walkthrough

Adds new and updated documentation supporting an in-progress monorepo merger between react_on_rails and react_on_rails_pro: licensing guidance, FAQ, merger plan reference, and a CONTRIBUTING.md note. No code, executable logic, or control-flow changes.

Changes

Cohort / File(s)	Summary
Licensing & Merger Docs docs/DIRECTORY_LICENSING.md, docs/LICENSING_FAQ.md, docs/MONOREPO_MERGER_PLAN_REF.md	New documents describing post-merger licensing boundaries (MIT vs Pro), contributor guidelines, automated CI license checks, a 7-phase merger plan reference, and FAQ scenarios.
Merger Plan metadata docs/MONOREPO_MERGER_PLAN.md	Updated metadata/date field to 2025-09-24; no behavioral changes.
Contributing CONTRIBUTING.md	Added editorial note about the in-progress monorepo merger with link to plan and transition guidance; no code changes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Chore/license files #1763 — Coordinated licensing/Core vs Pro artifacts for the monorepo merger.

Suggested reviewers

• justin808
• Romex91
• Judahmeek

Poem

I nibble through docs, with whiskers bright,
MIT fields left, Pro glows at night.
Seven-step path, every clause in sight,
CI hums a tune to keep it right.
Hop—merge day coming, what a delight! 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title clearly summarizes the key changes by stating the enhancement of contribution guidelines and the addition of a licensing FAQ for the monorepo transition, matching the pull request’s primary objectives without extraneous detail or ambiguity.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch prepare-licenses

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8772210 and 838b28b.

📒 Files selected for processing (2)

• docs/MONOREPO_MERGER_PLAN.md (1 hunks)
• docs/MONOREPO_MERGER_PLAN_REF.md (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• docs/MONOREPO_MERGER_PLAN.md

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/MONOREPO_MERGER_PLAN_REF.md

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)

• GitHub Check: dummy-app-integration-tests (3.4, 22)
• GitHub Check: dummy-app-integration-tests (3.2, 20)
• GitHub Check: claude-review
• GitHub Check: rspec-package-tests (3.2, minimum)
• GitHub Check: build
• GitHub Check: rspec-package-tests (3.4, latest)
• GitHub Check: rspec-package-tests (3.4, minimum)
• GitHub Check: rspec-package-tests (3.2, latest)

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Pull Request Review

Overall Assessment

This PR adds important documentation for the monorepo merger plan and licensing structure. The documentation is comprehensive and well-structured, providing clear guidance for contributors during the transition period.

✅ Strengths

• Clear communication: The documentation effectively communicates the licensing boundaries and merger plan
• Comprehensive coverage: All major aspects of licensing and the merger are covered
• Helpful FAQs: The LICENSING_FAQ.md addresses key concerns users might have
• Proper directory structure documentation: DIRECTORY_LICENSING.md clearly shows current vs. future state

🔍 Issues & Recommendations

1. Incomplete PR Description ⚠️

The PR description still contains the template placeholders and lacks a proper summary. Please update it to:

• Remove template instructions
• Add a clear summary of what this PR accomplishes
• Mark completed checklist items or remove if not applicable

2. Missing Trailing Newlines 🚨

Per CLAUDE.md requirements, all files must end with a newline character. Please ensure all new files have trailing newlines.

3. Broken Link in MONOREPO_MERGER_PLAN_REF.md 🔗

Line 5 contains an absolute path that will not work on GitHub:
/mnt/ssd/react_on_rails_workspace/react_on_rails/docs/MONOREPO_MERGER_PLAN.md

Should be: ./MONOREPO_MERGER_PLAN.md (relative path)

4. Consider Adding License Headers 📝

While the documents describe licensing, consider adding explicit license headers to the new documentation files themselves for clarity.

📋 Test Coverage

No tests required as this is documentation-only, but consider:

• Verifying all internal links work correctly
• Running markdown linter to ensure consistent formatting

🔒 Security Considerations

No security concerns - documentation only.

🎯 Performance Considerations

N/A - documentation changes only.

📈 Suggestions for Enhancement

1. Consider adding a visual diagram showing the monorepo structure
2. Add timeline estimates for each merger phase
3. Include migration scripts or tools references if they exist
4. Consider adding examples of what constitutes "Pro code" vs "MIT code"

✅ Approval Status

This PR is ready for merge once the following are addressed:

1. Fix the broken link in MONOREPO_MERGER_PLAN_REF.md
2. Update PR description with proper summary
3. Ensure all files have trailing newlines

Great work on documenting this important transition! The documentation will be valuable for contributors during the merger process.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (4)

docs/DIRECTORY_LICENSING.md (2)

11-35: Add explicit languages to the directory tree code blocks.

Our markdown tooling expects fenced blocks to declare a language. Tag these directory listings as text (or bash) to avoid lint failures.

-```
+```text
 react_on_rails/
 ├── lib/react_on_rails/           # Core Ruby code (MIT)
 ...

Do the same for the other directory listings in this file.

---

43-65: Same issue here—add a language to the fenced blocks.

Please apply the same text language annotation to this Pro directory listing so markdownlint passes.

-```
+```text
 react_on_rails/ (monorepo root)
 ├── lib/react_on_rails_pro/       # Pro Ruby code
 ...

docs/LICENSING_FAQ.md (1)

29-39: Declare a language for the directory tree code block.

This fenced block needs a language hint (e.g., text) to satisfy markdownlint.

-```
+```text
 react_on_rails/ (monorepo root)
 ├── lib/
 ...

CONTRIBUTING.md (1)

3-3: Convert bold announcement to a proper heading

Markdownlint (MD036) flags the bold text being used as a heading. Switching to an actual heading keeps the document consistent with the lint rules and the rest of the file structure.

-**🏗️ Important: Monorepo Merger in Progress**
+## 🏗️ Important: Monorepo Merger in Progress

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 199071c and 8772210.

📒 Files selected for processing (4)

• CONTRIBUTING.md (1 hunks)
• docs/DIRECTORY_LICENSING.md (1 hunks)
• docs/LICENSING_FAQ.md (1 hunks)
• docs/MONOREPO_MERGER_PLAN_REF.md (1 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

{Gemfile,Rakefile,**/*.{rb,rake,gemspec,ru,js,jsx,ts,tsx,json,yml,yaml,md,css,scss}}

📄 CodeRabbit inference engine (CLAUDE.md)

Ensure all committed files end with a trailing newline character

Files:

• CONTRIBUTING.md
• docs/DIRECTORY_LICENSING.md
• docs/MONOREPO_MERGER_PLAN_REF.md
• docs/LICENSING_FAQ.md

**/*.{js,jsx,ts,tsx,json,yml,yaml,md,css,scss}

📄 CodeRabbit inference engine (CLAUDE.md)

Let Prettier handle all non-Ruby file formatting; never manually format these files

Files:

• CONTRIBUTING.md
• docs/DIRECTORY_LICENSING.md
• docs/MONOREPO_MERGER_PLAN_REF.md
• docs/LICENSING_FAQ.md

🪛 markdownlint-cli2 (0.18.1)

CONTRIBUTING.md

3-3: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

docs/DIRECTORY_LICENSING.md

11-11: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

28-28: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

43-43: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

57-57: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

docs/LICENSING_FAQ.md

3-3: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

88-88: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

100-100: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

114-114: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

122-122: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

---

124-124: Bare URL used

(MD034, no-bare-urls)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)

• GitHub Check: dummy-app-integration-tests (3.4, 22)
• GitHub Check: dummy-app-integration-tests (3.2, 20)
• GitHub Check: build
• GitHub Check: rspec-package-tests (3.4, latest)
• GitHub Check: rspec-package-tests (3.2, minimum)
• GitHub Check: rspec-package-tests (3.4, minimum)
• GitHub Check: markdown-link-check
• GitHub Check: rspec-package-tests (3.2, latest)

[claude]

Code Review for PR #1819: Enhance contribution guidelines and add licensing FAQ for monorepo transition

Thank you for this comprehensive documentation PR! This is excellent preparatory work for Phase 1 of the monorepo merger. Here's my detailed review:

✅ Strengths

1. Thorough Documentation: The documentation coverage is comprehensive, addressing all critical aspects of the dual-licensing structure in the future monorepo
2. Clear License Boundaries: Excellent job defining MIT vs Pro directory structures and compliance rules
3. Phased Approach: The 7-phase merger plan is well-structured with clear success criteria
4. Developer-Friendly: The FAQ and guidelines provide practical guidance for contributors
5. No Breaking Changes: Documentation-only changes minimize risk

📋 Recommendations

1. PR Description Cleanup (Minor)

The PR description contains template placeholders that should be removed:

• Remove "Remove this paragraph and provide a general description..."
• Check/update the template checkboxes
• Customize the description for this specific PR

2. CHANGELOG Entry (Optional)

Consider adding a CHANGELOG entry under "Documentation" or "Unreleased" section if project standards require it

3. Documentation Maintenance Plan

With 289 lines of new documentation, consider:

• Adding a note about when/how these docs will be updated during implementation
• Marking temporary sections that will be removed post-merger

🔍 Code Quality & Best Practices

• ✅ Follows project structure - Documents properly placed in docs directory
• ✅ Clear writing - Well-organized with proper markdown formatting
• ✅ Comprehensive coverage - Addresses user, contributor, and maintainer perspectives
• ✅ License compliance - Strong focus on maintaining MIT/Pro boundaries

🚀 Performance & Security

• No performance impact - Documentation only
• Security considerations addressed - License compliance automation mentioned, which is crucial for preventing accidental Pro code exposure

✧ Test Coverage

Not applicable for documentation-only changes, but the PR mentions future automated license checking which is excellent.

💭 Overall Assessment

This is high-quality preparatory work that sets a solid foundation for the monorepo merger. The documentation is clear, comprehensive, and addresses the complex licensing requirements appropriately.

Recommendation: APPROVE after addressing the minor PR description cleanup.

The phased approach and emphasis on license compliance demonstrate careful planning for this architectural change. Great work on making the transition transparent and well-documented for the community!

---

Review based on commit 4fe3ad3 and project guidelines from CLAUDE.md

[claude]

Code Review for PR #1819 - Enhance contribution guidelines and add licensing FAQ for monorepo transition

Thank you for this well-structured documentation update for the monorepo transition! I have thoroughly reviewed the changes across all five modified files. Here is my comprehensive feedback:

✅ Strengths

1. Excellent Documentation Structure: The documentation is comprehensive, well-organized, and follows best practices for technical writing
2. Clear License Boundaries: The license separation between MIT and Pro is clearly defined, which is critical for the monorepo merger
3. Proper File Formatting: All files have proper trailing newlines as required by the CLAUDE.md guidelines
4. Comprehensive Coverage: The documentation covers all aspects of the merger from technical implementation to user impact

📋 Code Quality & Best Practices

The documentation changes are high quality with:

• Clear hierarchical structure with appropriate markdown headings
• Consistent formatting throughout all files
• Good use of examples and code snippets
• Proper cross-referencing between documents

🔍 Potential Issues

1. PR Description Incomplete: The PR body still contains the template placeholder text ("Remove this paragraph and provide a general description..."). Please update with actual summary of changes.

2. Missing Test Coverage Checkbox: The PR checklist items are not checked, particularly the "Add/update test to cover these changes" item. While these are documentation changes that do not require traditional tests, consider checking items as N/A with ~ wrapping as suggested in the template.

3. Phase 1 Status Clarity: The MONOREPO_MERGER_PLAN_REF.md indicates "Phase 1 - License Cleanup & Documentation (In Progress)" but this PR appears to be completing Phase 1. Consider updating the status or clarifying if additional work remains.

⚡ Performance Considerations

No performance concerns - these are documentation-only changes.

🔒 Security Considerations

The documentation appropriately addresses security through:

• Clear license compliance rules preventing Pro code from entering MIT directories
• Automated CI checks for license validation
• Explicit directory-level licensing boundaries

🧪 Test Coverage

While these documentation changes do not require traditional test coverage, the MONOREPO_MERGER_PLAN.md includes excellent provisions for automated testing:

• License compliance checker script
• CI integration for license verification
• Clear success criteria for each phase

💡 Suggestions for Improvement

1. Update PR Description: Replace the template text with a concrete summary of what this PR accomplishes
2. Complete PR Checklist: Mark items appropriately (use ~ for N/A items)
3. Add CHANGELOG Entry: Consider adding a CHANGELOG entry for this significant documentation update
4. Version Considerations: The plan references v15 in examples - ensure this aligns with current/upcoming versions

🎯 Minor Observations

• The documentation correctly emphasizes the critical importance of license compliance
• The phased approach with rollback procedures is well-thought-out
• The AI agent context section in MONOREPO_MERGER_PLAN.md is particularly helpful

✨ Overall Assessment

This is a well-executed documentation PR that provides excellent groundwork for the monorepo merger. The documentation is thorough, clear, and addresses all critical aspects of the transition. Once the PR description and checklist are updated, this should be ready to merge.

The monorepo merger plan is particularly impressive in its attention to detail, clear phase definitions, and emphasis on maintaining CI/license compliance throughout the process.

---

🤖 Generated with Claude Code