Collision Checks

Purpose

Collision checks protect existing owners when new addon routes, slugs, targets, permissions, or tables are introduced.

This is the developer-safe version of the rule: do not ship a package that silently overwrites another owner's address, identifier, or contract.

What can collide

• addon keys
• package slugs
• admin route keys
• public route paths
• public target identifiers
• menu target provider keys
• permission keys
• table names
• unique indexes
• frontend app slugs

Developer responsibility

Before releasing or installing an addon, check that its declared identifiers do not conflict with existing governed owners.

If a conflict exists, change the new addon unless the replacement is intentional, documented, and migration-safe.

Safe handling

A safe collision response should:

• identify both owners
• preserve the existing owner by default
• choose a new route/key/slug for the incoming package
• update public targets and menu references if needed
• verify both old and new routes still load

Bad handling

Do not silently replace an existing route. Do not rename another addon's keys to make your addon fit. Do not make a catalog or installer surface hide the problem.

A collision is not a negotiation with reality. Reality already has the route.