Greenfield Cutover — Preserve Connections, Delete Legacy State

Detailed record of what was retained, what was deleted, and why the platform was reset before rebuilding the three sites.

Decision

The rebuild is not a migration of the old products.

The useful assets are the infrastructure primitives and connection paths. The application state itself is disposable.

The preservation boundary is therefore:

Retain	Rebuild or delete
OCI compute instances	Legacy application code
Autonomous Database services	Existing application tables and data
Database wallets and TNS configuration	Legacy models and generated datasets
Object Storage bucket and OCI access path	Object Storage file contents
Domains and DNS control	Old site design
Secure MCP tunnels	Old schedules and workers

Blackdeck

The old Blackdeck application tree and its local generated data were removed.

The Object Storage integration was intentionally not removed. Its bucket and OCI authentication/configuration remain available so a future implementation can use Object Storage again if there is a clear reason to do so. Only the accumulated legacy objects are being purged.

The Autonomous Database service was also retained. A fresh wallet was generated and stored on the server with restrictive permissions. The application schema was cleared of legacy tables so the new product can define its own data model.

ByteCosmos

The previous crypto/Binance-oriented implementation was treated as a dead branch rather than a migration source.

The code, model files, logs, timers, and generated state were removed. The Autonomous Database connection was retained. Its database password had expired, so it was rotated in place and the server-side connection file was updated without exposing the credential in chat or source control.

Legacy application tables were then removed.

Runtime standardization

Both OCI servers now have the same common runtime:

Ubuntu ARM64
├─ Docker
├─ Docker Compose
├─ Caddy
├─ Git
├─ systemd
└─ OpenAI tunnel-client

The aim is not to introduce a large platform layer. These servers have limited resources, so the operational model remains small: containers, files, batch jobs, and explicit resource limits.

jintaechoi.com

The personal site shares the Blackdeck VM physically but is separated operationally.

It has:

its own project root
its own configuration directory
its own Git repository
its own container
its own internal port
explicit CPU and memory limits
hostname-based routing through Caddy

The public blog is Markdown-based. Private notes and the work dashboard require the administrator session. The administrator credential is created through a one-time HTTPS setup flow and is stored only as a password hash.

Result

The platform is now positioned for a true greenfield build. Future work should add only assets that support the new Blackdeck, ByteCosmos, and Personal Knowledge OS designs rather than recreating the old architecture by inertia.