Runtime state

Rudel is DB-backed only. JSON files are not part of the supported runtime model for apps, environments, domains, worktrees, or deployment history.

That means:

• the bootstrap resolves apps and environments from WordPress tables
• managers and public APIs read and write state through repositories and services
• Divine or any other integrator can reference Rudel records by stable DB IDs

Tables

Rudel creates a small set of runtime tables:

• wp_rudel_environments
• wp_rudel_apps
• wp_rudel_app_domains
• wp_rudel_worktrees
• wp_rudel_app_deployments

wp_rudel_environments is the main record for both apps and sandboxes. It stores identifiers, paths, engine, lifecycle state, policy metadata, lineage, timestamps, and optional GitHub linkage.

wp_rudel_apps gives long-lived apps their own stable DB identity, separate from the environment row that represents the app's runtime directory.

wp_rudel_app_domains stores normalized domain mappings and enforces uniqueness so two apps cannot claim the same domain.

wp_rudel_worktrees stores extracted worktree metadata separately from the broader clone-source payload so worktree state can be queried and updated directly.

wp_rudel_app_deployments stores deploy history, deploy labels/notes, source sandbox linkage, backup references, and tracked GitHub context for rollbacks and audit trails.

Service boundaries

Rudel's live runtime reads and writes should go through repositories and services rather than reading files directly:

• EnvironmentRepository owns environment persistence and lookup
• AppRepository owns app identity and domain mappings
• EnvironmentWorktreeRepository owns worktree rows
• AppDeploymentRepository owns deployment history
• managers and higher-level services compose those repositories for lifecycle operations

The filesystem still matters for isolated wp-content, SQLite databases, backups, templates, snapshots, and exported archives. It does not define which apps or environments exist.