SQLite CLI Availability Decision

Purpose

This page records the current options for obtaining a local SQLite execution engine without changing project dependencies, package scripts, active migrations, or app runtime behavior.

SQL activation remains blocked until a safe local engine path is chosen and later verified in a separate phase.

Current Dry-Run Result

Manual result

skipped-sql-engine-unavailable

Validator

passed

sqlite3 detection

unavailable

Activation readiness

blocked

SQL executed	D1 target	Wrangler usage	Production target	Preview target	Tables created
false	none	none	none	none	none

Decision Options

Local sqlite3 outside the project

recommended safest executable path if migration work continues

Risk: lowest-executable-risk

decision-only

make sqlite3 available on the local machine outside repo/package dependencies
keep package.json dependencies unchanged
keep package scripts unchanged
continue requiring the manual --local-disposable-only flag
keep all SQL execution disposable and local

Benefits: allows the draft SQL to be execution-verified without adding a project dependency; keeps the app runtime dependency-free; avoids D1, wrangler, production, and preview targets; preserves current active migration isolation.

Drawbacks: requires local workstation setup outside the repo; availability may vary across machines; does not by itself approve migration activation.

Boundaries: no project dependency; no package script; no D1 target; no wrangler usage; no active migration; no app data writes; no CRUD UI.

Approved dev-only SQLite dependency

possible later, not recommended yet

Risk: higher-approval-required

decision-only

explicit approval before any dependency is added
dependency must be dev-only
dependency must stay out of app runtime imports
package scripts must not execute SQL automatically

Benefits: could make local dry-run verification reproducible; could avoid workstation-level CLI differences; can remain local-only if tightly scoped.

Drawbacks: adds dependency and supply-chain surface; increases risk of runtime coupling; not needed until the local CLI path is ruled out.

Boundaries: not approved in this phase; no production dependency; no automatic SQL path; no D1 target; no active migration; no write endpoints.

Continue safe skip

safe fallback, but it blocks migration activation

Risk: lowest-current-risk

decision-only

keep SKIPPED_SQL_ENGINE_UNAVAILABLE as an acceptable result when sqlite3 is unavailable
do not treat skipped SQL as a successful dry run
keep activation blocked
keep validator and safety scans active

Benefits: preserves the safest no-execution posture; requires no dependency or local tooling change; keeps D1 and wrangler out of the path.

Drawbacks: SQL draft remains unverified by execution; no table creation evidence exists; migration activation remains blocked.

Boundaries: no SQL execution; no dependencies; no D1 target; no active migration; no app writes; no CRUD UI.

Pause migration track

acceptable if account/pull-up architecture is the higher-value next product line

Risk: product-priority-choice

decision-only

leave the role-set migration draft inactive
do not add a SQLite engine path yet
return planning attention to account architecture and pull-up/push-up gates
keep role-set storage and CRUD blocked

Benefits: focuses product work on account and workflow decisions before storage activation; avoids tooling work if migration activation is not urgent; keeps all storage boundaries unchanged.

Drawbacks: delays role-set template execution verification; keeps migration activation blocked; leaves config-only CRUD work in planning mode.

Boundaries: no SQL execution; no dependency installation; no active migrations; no account creation; no submissions; no role assignment.

Recommended Path

SQL activation remains blocked.
The safest executable path is making local sqlite3 available outside the project.
No dependency should be added yet.
No package script should execute SQL.
If migration work is paused, the next product phase should return to account/pull-up architecture.

What Remains Blocked

No dependency, active migration, automatic SQL execution, D1 target, wrangler command, production or preview database target, write endpoint, CRUD UI, role-set storage, account, identity capture, submission workflow, tracking, analytics, scoring, or sensitive storage is active.

dependency installation
SQLite dependency installation
SQL execution in this phase
D1 targeting
wrangler usage
production or preview database targeting
active migrations
runtime database queries
database writes
write endpoints
role-set runtime storage
CRUD UI
account creation
login
user assignment
role assignment
identity capture
identity storage
live submissions
staff decisions
attendance tracking
participation tracking
participation analytics
scoring, ranking, discipline points, or compliance metrics
billing or lead capture
sensitive community content storage

What Must Not Change

Package dependencies and package scripts must remain unchanged. The active migrations folder must remain isolated. The app must not run SQL, target D1, use wrangler, create tables, write data, or expose migration controls.

Next Implementation Choice

Phase 7.17 - Local SQLite CLI Dry-Run Execution Review

continue-migration-line

conditional-next

local sqlite3 is made available outside the project
manual disposable dry-run is run only with --local-disposable-only
no D1, wrangler, production, preview, dependency, active migration, write endpoint, or CRUD path is added

Phase 8.0 - Account Architecture and Pull-Up/Push-Up Live Workflow Gate Review

pause-migration-line

conditional-next

migration activation remains blocked
role-set storage remains inactive
account and pull-up/push-up architecture is prioritized without creating accounts or submissions

No activation yet, no active migrations yet, no CRUD yet, no accounts yet, and no submissions yet.