Skip to content

docs: org-level ecosystem overview - #7

Merged
asafgolombek merged 1 commit into
mainfrom
dev/asafgolombek/ecosystem-overview
Jul 28, 2026
Merged

docs: org-level ecosystem overview#7
asafgolombek merged 1 commit into
mainfrom
dev/asafgolombek/ecosystem-overview

Conversation

@asafgolombek

Copy link
Copy Markdown
Contributor

Why

Nimbus/docs/ecosystem-roadmap.md was closed on 2026-07-24, but it still carried the only description of how the whole ecosystem fits together — the repo map, the one-way contract rule, and which document owns which planning question. That content has no business living inside one of the repositories it describes.

This is the org-level home for it. General information about the ecosystem as a whole; no sequencing, no roadmap.

What it contains

  • The shape — a diagram of surfaces → gateway → connectors, and the rule that no surface talks to a cloud service directly
  • The one-way contract rule, stated explicitly because it is the constraint most likely to be violated by accident: the SDK and client are MIT, the gateway is AGPL-3.0, so shared types must live in nimbus-sdk and be imported by the gateway — MIT flows into AGPL, the reverse would infect
  • All 18 repositories, grouped by role: core, surfaces, connectors/extensions, distribution, project infrastructure
  • Where planning lives — one question per document, with the tiebreak rule
  • The six non-negotiables that hold ecosystem-wide

Corrections from the live inventory

The old repo map in ecosystem-roadmap.md was stale in two ways, both fixed here by reading gh api orgs/nimbus-agent/repos:

  • it listed 8 repositories; there are 18
  • it described nimbus-mcp-servers as "Proposed"; the repository exists

The planning-ownership statement

This document states that there is deliberately no separate cross-surface roadmap. Sequencing — which surface should exist next, and why that one first — is a product question and belongs in the gateway's roadmap alongside everything else it sequences.

That resolves a live three-way conflict: ecosystem-roadmap.md says it is closed and each surface is owned by its own repo; nimbus-client/ROADMAP.md claims the vacated cross-surface role; nimbus-vscode and nimbus-sdk still point at the closed document as authoritative. Follow-up PRs in those repos will align them with the table here.

🤖 Generated with Claude Code

The Nimbus repo carried docs/ecosystem-roadmap.md, which was closed on
2026-07-24 but still described how the whole ecosystem fits together —
the one part of it that had no other home. That belongs at org level,
not inside one of the repos it describes.

This is the general overview: the shape of the system, the repository
map, the one-way contract rule, and which document owns which planning
question.

Two things the old repo map got wrong, corrected here from the live org
inventory: it listed 8 repositories when there are 18, and it described
nimbus-mcp-servers as "proposed" when the repository exists.

Records the load-bearing licensing rule explicitly, because it is the
constraint most likely to be violated by accident: the SDK and client
are MIT, the gateway is AGPL-3.0, so shared types MUST live in
nimbus-sdk and be imported by the gateway. MIT flows into AGPL; the
reverse would infect. The licence choice is what keeps the dependency
arrow pointing the only direction that works.

Also states that there is deliberately no cross-surface roadmap:
sequencing is a product question owned by the gateway's roadmap. A
second sequencing document is how two files came to claim the same
authority in the first place.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 28, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4c81d6a3-3788-445c-be36-1d73692bf31b

📥 Commits

Reviewing files that changed from the base of the PR and between 54945a1 and 5db2716.

📒 Files selected for processing (1)
  • ECOSYSTEM.md
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch dev/asafgolombek/ecosystem-overview

Comment @coderabbitai help to get the list of available commands.

@sonarqubecloud

Copy link
Copy Markdown

@asafgolombek
asafgolombek merged commit 2895990 into main Jul 28, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant