WiredTiger in containers and controllership discovery
A day of turning an incident into technical content, publishing the previous daily entry, and deepening product discovery around margin and automation.
The day started by closing the loop on /daily itself: I reviewed the June 9, 2026 entry, made sure only the journal files were in the diff, validated Velite, scanned for long dashes and obvious sensitive patterns, and opened the PR with the bilingual entry. It was a useful reminder that the journal only works when the publishing routine is small, predictable, and auditable.
From incident to technical post
I went back to the iTOP memory problem on the VPS running Dokploy and MongoDB. The missing piece was WiredTiger cache inside containers: two mongod instances on a small machine were competing for RAM with Next.js, Dokploy, and the build. From there, I turned the diagnosis into a bilingual blog post, explaining why the build died without a clear error, how the WiredTiger cache formula behaves in containers, and why the problem felt random when it was really memory pressure.
I also left with a practical production runbook: add swap as a safety net, reduce wiredTigerEngineRuntimeConfig at runtime with setParameter, persist the setting later, and monitor whether RAM actually returns to a healthy range. It was a fix designed for changing the system while it keeps running.
Controllership before code
On the accounting project, the work was less about code and more about clarity. I repositioned the PRD as a thin controllership layer over an existing finance tool, with margin as the core of the product. Instead of building a generic ERP, the thesis became simpler: buy what already solves capture, entry, and reconciliation, and build the part that carries specific operational, margin, and decision intelligence.
That produced a decision one-pager, docs for the margin module, a requirements elicitation guide, an as-is flow to map the current pain, and a short list of sharp questions. The central question became clear: what does the current tool not solve in the real pain?
Agent trails
I also studied a utility that turns AI sessions into Git-versioned artifacts. The idea fits the /daily habit itself: preserve context, connect decisions to commits and PRs, and clean sensitive data before publishing any trace.
It was a day of turning fog into structure: an incident became a post and a runbook, and a product idea became better questions.