feat: add Ekklesia doctor command
This commit is contained in:
@@ -15,7 +15,9 @@ destructive-change declarations, and exact checksums. Core now provides read-onl
|
||||
planning and a locked, whole-batch transactional PostgreSQL runner with exact external destructive
|
||||
approval matching. A hermetic live PostgreSQL suite now proves history, rollback, statement
|
||||
breakpoints, advisory-lock concurrency and release, exact destructive approvals, and sanitization
|
||||
against the production adapter. Production approval-provider composition, identity, HTTP routing,
|
||||
against the production adapter. A Core-owned `pnpm doctor` dashboard now combines the existing
|
||||
static discovery and read-only migration-planning services into one concise readiness report.
|
||||
Phase 4 identity with Better Auth is next; production approval-provider composition, HTTP routing,
|
||||
jobs, physical storage provisioning, surfaces, and feature modules remain later vertical slices.
|
||||
|
||||
## Quick start
|
||||
@@ -28,11 +30,57 @@ cp .env.example .env
|
||||
pnpm infrastructure:up
|
||||
pnpm modules:validate
|
||||
pnpm migrations:validate
|
||||
pnpm doctor
|
||||
pnpm migrations:plan
|
||||
pnpm test:migrations:integration
|
||||
pnpm verify
|
||||
```
|
||||
|
||||
`pnpm doctor` builds the workspace first, then reports the supported Node.js runtime, installed
|
||||
modules and dependency order, schema and migration inventories, optional read-only PostgreSQL
|
||||
planning, and the current object-storage integration state. It never applies migrations, creates a
|
||||
history table, starts module servers, or performs storage operations. Schema discovery does import
|
||||
compiled schema-definition entrypoints; those entrypoints are contractually side-effect-free.
|
||||
|
||||
With no installed modules and no `DATABASE_URL`, the current repository produces a report shaped
|
||||
like this:
|
||||
|
||||
```text
|
||||
Ekklesia Doctor
|
||||
|
||||
Platform
|
||||
✓ Runtime version supported
|
||||
Active Node.js satisfies the declared supported range.
|
||||
|
||||
Modules
|
||||
✓ Module discovery complete
|
||||
0 modules installed
|
||||
✓ Dependency graph valid
|
||||
Dependency order is empty.
|
||||
|
||||
Data definitions
|
||||
✓ Schemas validated
|
||||
0 modules · 0 tables
|
||||
✓ Migrations validated
|
||||
0 migrations · checksums valid
|
||||
|
||||
PostgreSQL
|
||||
○ Connection check skipped
|
||||
DATABASE_URL is not configured.
|
||||
○ Migration plan skipped
|
||||
A validated migration inventory and configured PostgreSQL connection are required.
|
||||
|
||||
Object storage
|
||||
○ Check unavailable
|
||||
Core storage integration has not been implemented yet.
|
||||
|
||||
Result: READY WITH WARNINGS
|
||||
```
|
||||
|
||||
Checks have stable pass, warning, failure, or skipped states. Warnings and skipped optional checks
|
||||
produce `READY WITH WARNINGS` and exit zero; any failure produces `NOT READY` and exit one. The
|
||||
dashboard is human-readable local guidance, not a replacement for automated CI evidence.
|
||||
|
||||
`pnpm migrations:plan` uses `DATABASE_URL` from the uncommitted `.env` and is read-only.
|
||||
`pnpm migrations:apply` uses the same validated inventory but mutates PostgreSQL under Core's
|
||||
advisory lock and one transaction. Review the plan before applying. Destructive migrations are
|
||||
|
||||
Reference in New Issue
Block a user