Projects
A project is the main unit of ownership in MergeSafe. It is the boundary that groups a product surface, the tools exposed from it, the domains allowed to load it, the pack versions published from it, and the operational data collected after launch.
What a project is
Use project as the first structural concept in MergeSafe docs. Projects are not a cosmetic folder layer. They define which domains, tools, versions, and operational records belong together.
That makes the project the safest place to explain ownership, rollout scope, and release state. If a team is exposing one product surface through MergeSafe, it should be able to explain that surface in project terms.
What a project owns
- Domains used for origin-based runtime access decisions.
- Manual tool definitions, including schemas and binding configuration.
- Published pack versions and the active version pointer.
- Telemetry, analytics, and tool health rollups collected after runtime activity.
- Install and runtime delivery surfaces such as the frontend snippet and current artifact view that are derived from project state.
Why project is the top-level boundary
- Release state is project-scoped, so publish and active-version changes affect one project at a time.
- Runtime authorization starts from project-level domain configuration rather than from individual tools.
- Operational visibility such as analytics and health rollups attaches back to the project that owns the tools.
- Multiple domains per project are supported, so one project can still represent a broader product surface when needed.
How to talk about the project key safely
Project creation generates a project key. It is safe to describe that key as a real project-scoped credential or identifier that appears in project management and telemetry-related flows.
Docs should stay careful when discussing active pack delivery. The audited docs truth confirms project-key authentication for telemetry ingestion, but it does not confirm a product rule that active pack fetch always requires the project key.
Keep the project-key claim narrow
Do not state as a guaranteed runtime-delivery fact that the project key is required for active pointer or artifact access until that behavior is manually verified.
How projects relate to the rest of the model
- Domains
- Domains attach to a project and determine which origins are allowed to load project runtime state.
- Tools
- Tools are authored inside a project, then compiled into project pack versions during publish.
- Packs and Versions
- Pack versions are created per project, and one project version is active at a time.
- Telemetry and Health
- Runtime events roll up into project-level analytics and tool health views after launch.