In my last post, I signed off with a simple plan: test the “Save to GitHub” feature and deploy. But as I started using the tool, I realized that saving Markdown files to a repo was only half the solution.
If I truly want to build an “Engineering Intelligence” tool, I need more than just file storage. I need a brain. I need a database that can query, filter, and analyze the logs. I want to track my own development velocity alongside the project itself.
The last few weekends have been about pivoting from a simple WordPress Plugin (v1.0.0) to a full Microservices Architecture (v1.1.0).
1. The Pivot: Building the “Brain” (ddh-core)
I realized that while WordPress is great for the Journaling interface, it shouldn’t handle the heavy lifting of engineering telemetry. I needed a dedicated backend to store the data properly.
I spun up ddh-core, a TypeScript/Node.js application running in Docker. This serves as the centralized API for everything, extending this personal project into a platform where other developers can eventually store their own data.
The Goal: A single source of truth that accepts data from anywhere—my WordPress dashboard or my terminal.
2. The Architecture: The “Two-Stream” Epiphany
One of the biggest hurdles I faced was a “Vision vs. Reality” mismatch in my database.
I was trying to shove two very different types of data into one table.
- The Manager’s View (WordPress): High-level summaries, Q&A format, reflection.
- The Engineer’s View (CLI): Nitty-gritty details, technical blockers, “scope,” and “friction.”
Recent application tests were crashing with 500 errors because the columns didn’t match. The breakthrough came when I decided to split the architecture into Two Streams:
journal_logs: Stores the reflective content from the WP Admin dashboard.engineering_logs: Stores the technical data pushed from the CLI.
This separation allows me to wear “different hats” (Manager vs. Maker) without breaking the database schema. If we combine the WP Admin journal logs with engineering logs and Trello cards, we have three-dimensional data, logical connections between the scripting and the abstractions.
3. The “Messy Middle”: Dependency Injection & Zombie Containers
I’ll be honest, this part was a grind. I have had a few rounds of battling “Zombie Containers” (Docker containers that refused to die and held onto old database names) and debugging TypeScript errors.
I hit a wall with Dependency Injection. I had wired my application to pass the database connection (the “Pool”) from file to file like a bucket brigade. It became a tangled mess that crashed my routes.
I learned a valuable lesson here: simpler is often better. I refactored the app to use Direct Imports for the database connection. The result? Cleaner code, fewer files, and it just works.
4. The Win: 201 Created
After days of ECONNREFUSED and 401 Unauthorized errors, I finally got the green light.
I updated my testing workflow (moving from manual copy-pasting to automated variables in VS Code) and ran the full suite.
- Register/Login: ✅ (with secure password hashing)
- WP Journal Entry: ✅ (201 Created)
- CLI Engineering Log: ✅ (201 Created)
What’s Next?
Right now, this “Brain” is living in a containerized environment on Railway. The foundation is no longer just “laid.” It’s poured, cured, and ready to bear weight.
I just added a new machine to my home office and will be using the new Daily Dev Habit CLI tool to document the setup of a native app project. I have already created a copy of the first version CLI tool to be modified for use with other CLI tools.