[Governance] Separate ecosystem integrations from EverOS core

[cyfyifanchen]

Context

PR #410 made an architectural boundary explicit: EverOS core capabilities and ecosystem integrations have different ownership, release, dependency, and maintenance lifecycles.

The repository should adopt a clear default rule:

Ecosystem code is ecosystem code; core code is core code. They should not be mixed unless there is a specific, documented reason.

Keeping an ecosystem integration in the EverOS repository may sometimes be justified for discoverability, adoption, or a tighter contributor experience. That is a repository-placement decision, not permission to couple product-specific implementation details into the core runtime.

Boundary

Core code

Code belongs in the EverOS core only when it:

• provides a generic capability reusable by multiple integrations;
• has no dependency on one host, agent, plugin protocol, or product;
• is part of the supported EverOS API or runtime contract;
• is tested and documented as an EverOS capability.

For example, a generic deferred-ingestion API may belong in the core. A DeepSeek Harness lifecycle adapter does not.

Ecosystem code

Host- or product-specific code belongs in an ecosystem package, normally either:

1. a dedicated ecosystem repository; or
2. a self-contained directory under examples/<integration> when keeping it in the EverOS repository has a clear product or discovery benefit.

This includes host adapters, plugin manifests, provider-specific configuration, installation scripts, host lifecycle hooks, and ecosystem-specific tests.

Rules for examples/

Every non-trivial integration under examples/ should behave like an independently owned package:

• all integration-specific source, tests, documentation, manifests, and configuration stay inside examples/<integration>;
• dependencies and lockfiles are isolated from the EverOS core;
• the integration has path-scoped CI that runs its lint, tests, build, and package checks;
• the integration defines its own supported runtime and EverOS compatibility;
• the integration is not included in the core wheel/sdist unless explicitly approved;
• core code must never import from examples/;
• example code may call stable public EverOS APIs, but should not depend on private core internals;
• security boundaries must be documented, including credentials, network access, process execution, permissions, untrusted content, and supply-chain behavior;
• ownership and publishing responsibility must be clear.

Exceptions

If a PR mixes ecosystem-specific behavior into core code, its description must explain:

1. why the behavior is a reusable EverOS capability rather than an integration detail;
2. which other integrations can use it;
3. why a public API or adapter-local implementation is insufficient;
4. what dependency, compatibility, security, and maintenance costs it adds;
5. how the core remains independent of the originating ecosystem.

“Convenient for this plugin” is not enough. Promotion or discoverability may justify keeping an integration in the main repository under examples/, but does not justify coupling its implementation into src/everos.

Proposed repository changes

• Document this boundary in CONTRIBUTING.md or the engineering documentation.
• Add a PR-template checklist item for core vs. ecosystem classification.
• Define a lightweight template for publishable examples/<integration> packages.
• Require path-scoped CI for non-trivial examples.
• Document the exception-justification format.
• Audit existing examples/ directories and identify code that should be isolated, moved, or explicitly justified.

Acceptance criteria

• Contributors can determine whether new code belongs in core, examples/, or a separate ecosystem repository.
• New ecosystem integrations do not add host-specific dependencies or implementation details to the EverOS core.
• Every approved exception includes a reviewable written rationale.
• Non-trivial examples are independently testable, maintainable, and publishable.
• Repository growth remains intentional and does not weaken the core package boundary.

Related: #410.