Adding a Future Extension
A gated pattern for new vehicle categories, media types, payments, AI, or clients.
Model the future capability first, then keep it disabled until its contracts and release gates exist.
Source boundary
Source boundary: AutoCore current main 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60, checked against immutable v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f.
Future scope belongs in explicit capability models and feature flags. MVP remains passenger cars for the primary market; extension work must preserve API versioning, mobile compatibility, i18n, security, and migration safety.
| Check | Source-backed expectation |
|---|---|
| Scope | Do not activate future scope merely because the schema can represent it. |
| Evidence | Use placeholders, timestamps, release identity, route, status, and request ID where relevant. |
| Safe action | pnpm edition:verify |
| Stop condition | Unknown authorization, destructive impact, secret exposure, or conflicting evidence. |
Verification
Run the safe check, record its result, and compare the outcome with the documented contract. If the result depends on external configuration or provider availability, mark it as configuration-dependent rather than claiming a product guarantee.
pnpm edition:verify
Safety boundary
Examples are non-production and use placeholders. Do not deploy, reset, force a migration, create secrets, activate providers, replay sensitive work, or expose private data from this page.