Connecting Specdrive

Specdrive can guide work in either an existing codebase or a new Supacharger application. In both cases, keep Supacharger Core as the reusable source of truth and keep product behaviour in developer-owned seams.

Brownfield codebase

Start with an inventory rather than replacing folders wholesale:

1. record the existing authentication, roles, database objects, routes, styling and product-specific behaviour;
2. compare those contracts with the Core lock and ownership manifest;
3. classify each difference as exact managed Core, merge-managed configuration, forward-only migration history, or developer-owned product code;
4. promote reusable behaviour to Core first, then update documentation and consumers;
5. preserve the existing migration ledger and adapt only through new forward migrations;
6. run the CLI plan, review collisions, update, verify exact hashes, and advance the lock only to a reachable Core commit.

Specdrive may retain licensed or product-specific presentation in developer-owned CSS, adapters and (project) routes. Reusable Auth, claims, route protection, organisation and API contracts belong in Core.

New project

For a new application, install the released Core with the Supacharger CLI, then configure the developer-owned files:

• src/supacharger.config.ts for feature policy and routes;
• src/styles/ for the product's semantic auth, account and organisation presentation;
• src/supacharger.adapters/ for product composition and extensions;
• src/app/(project)/ for product routes;
• messages/ for complete English source copy and deliberate translations;
• supabase/templates/ and new migrations for product-owned database extensions.

Connect the resulting implementation work to Specdrive in small, testable slices. Each slice should state the Core contract it uses, its product-owned extension, its migration or deployment consequence, and its acceptance evidence.