feat: add Ekklesia doctor command

docs/architecture/platform-architecture.md

@@ -70,8 +70,15 @@ now compare that inventory with its fixed PostgreSQL history table, produce a re
 apply the complete pending batch under a session advisory lock and one transaction. Destructive
 migrations require an exact externally supplied approval bound to module, identity, and checksum.
 Hermetic integration coverage now exercises those contracts through the production adapter against
-the pinned PostgreSQL container, including real DDL rollback and advisory-lock concurrency.
+the pinned PostgreSQL container, including real DDL rollback and advisory-lock concurrency. The
+Core-owned Doctor composes those existing services into a deterministic terminal readiness report:
+static module, schema, and migration validation always run when their prerequisites succeed, while
+PostgreSQL history planning runs only when configured. Schema inspection evaluates compiled schema
+definition entrypoints, which the module contract requires to be side-effect-free; Doctor never
+imports or starts module server entrypoints. It does not apply migrations or modify PostgreSQL, and
+it honestly skips object storage because no production Core storage service exists yet.
 
-Target architecture, not yet implemented: production approval-provider composition, Better Auth,
-permission enforcement, physical storage-bucket provisioning, Surface SDK, richer public resource
-and action contracts, API server, dashboard, Builder, and reference feature modules.
+The next architectural phase is Phase 4 identity with Better Auth. Other target architecture not
+yet implemented includes production approval-provider composition, permission enforcement,
+physical storage-bucket provisioning, Surface SDK, richer public resource and action contracts,
+API server, dashboard, Builder, and reference feature modules.

docs/development/repository-workflow.md

@@ -22,6 +22,7 @@ pnpm modules:validate # installed module manifests, compatibility, and dependenc
 pnpm migrations:validate # offline module migration inventory and exact checksums
 pnpm migrations:plan # read-only comparison with PostgreSQL applied history
 pnpm migrations:apply # locked, transactional application of the pending batch
+pnpm doctor        # build-first, read-only human readiness dashboard
 pnpm typecheck     # strict TypeScript
 pnpm test          # Vitest
 pnpm test:migrations:integration # production runner against disposable PostgreSQL
@@ -44,6 +45,76 @@ checks every declared stable Drizzle migration directory. It reports dependency-
 inventories and exact SHA-256 checksums without importing module code, connecting to PostgreSQL, or
 executing SQL. Modules with no migration history are valid.
 
+## Developer Doctor
+
+Run the complete local readiness dashboard with:
+
+```bash
+pnpm doctor
+```
+
+The root command follows the repository's build-first convention, so it works from a clean checkout
+without preexisting ignored `dist` output. The build itself may create ignored compiled artifacts;
+the diagnostics that follow are operationally read-only. Doctor never edits configuration, applies
+migrations, creates the Core history table, acquires the migration apply lock, starts module server
+entrypoints, provisions storage, or invokes Docker.
+
+Doctor reports a fixed, deterministic set of checks:
+
+- The active Node.js version against the repository's declared engine range.
+- Static module discovery and dependency-first ordering.
+- Schema discovery, including validated module and table counts. This imports compiled schema
+  definitions, which the module contract requires to perform no configuration reads, I/O, or
+  database connection.
+- Offline migration discovery, with safe identities and consistently truncated checksums.
+- PostgreSQL connectivity and read-only applied-history planning when `DATABASE_URL` is configured.
+- Object storage as skipped while Core has no production storage client or configuration contract.
+
+Every check has a stable ID and one of four states: pass, warning, failure, or skipped. Independent
+checks continue after a failure; a failed prerequisite causes only its dependent checks to be
+skipped. Pending or approval-blocked migrations are warnings and are never applied. Invalid
+history, checksum disagreement, unknown applied migrations, or a failed configured connection are
+failures. If `DATABASE_URL` is missing, PostgreSQL is skipped and all static checks still run.
+
+`READY` means every check passed. `READY WITH WARNINGS` means no check failed but at least one check
+warned or was skipped. Both results exit zero. `NOT READY` means at least one check failed and exits
+one. Meaning never depends on color, a TTY, timestamps, or interactive input.
+
+For the current repository with no installed modules and no `DATABASE_URL`, the concise inventory
+ends like this:
+
+```text
+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
+```
+
+Doctor is a local, human-readable summary. `pnpm verify`, `pnpm ci:verify`, infrastructure smoke,
+and migration smoke remain the authoritative automated evidence because they exercise formatting,
+boundaries, types, tests, builds, containers, and live mutation/rollback behavior that Doctor does
+not repeat. Phase 4 identity with Better Auth is the next architectural phase; Doctor does not
+diagnose identity, authorization, HTTP routing, runtime module health, or production storage yet.
+
 Migration planning and application require `DATABASE_URL`. Keep it in the uncommitted `.env`
 created from `.env.example`:
 

docs/module-development/README.md

@@ -241,6 +241,7 @@ From the repository root, run:
 pnpm install
 pnpm modules:validate
 pnpm migrations:validate
+pnpm doctor
 pnpm migrations:plan
 pnpm verify
 ```
@@ -281,6 +282,16 @@ PostgreSQL, including DDL rollback, advisory-lock contention, history behavior,
 sanitized failures. It remains outside the Docker-free `pnpm verify` gate; see the
 [testing guide](../development/testing.md).
 
+`pnpm doctor` builds first and presents the same production discovery results as a concise,
+read-only dashboard. It lists discovered module IDs and versions in dependency order, reports
+schema and migration counts, and shows safe migration identities with truncated checksums. Schema
+discovery imports the compiled schema-definition entrypoint, so its no-I/O and no-configuration
+contract still applies. Doctor does not import or start module server entrypoints, apply migrations,
+or exercise runtime hooks; lifecycle behavior remains covered by automated tests. PostgreSQL
+planning is skipped when `DATABASE_URL` is absent, and object storage is skipped until Core has a
+production storage integration. A skip or pending migration is visible as `READY WITH WARNINGS`,
+not misreported as a successful check.
+
 Core completes discovery before importing any server entrypoint. It then loads and verifies every
 runtime definition before running hooks, registers all modules dependency-first into an unpublished
 staged capability registry, and starts them in the same order. Shutdown is reverse-order. If a later