02 / Blog
Notes from practice
This blog is my external memory. It collects solutions, questions, and those small technical light-bulb moments that usually appear shortly after the third failed attempt.
Restore production into staging without replaying external effects
A safe restore checks more than backups: it pauses writers, neutralizes pending work, and keeps mail and backup access out of staging.
A forced-command SSH boundary for a Codex worker
Why the Homepage worker reaches Codex only through aidev on the AI CLI server without turning SSH into general remote access.
Schema-valid AI jobs outside the TYPO3 request
How TYPO3 runs AI work as a bounded job, validates responses twice, and keeps slow processing outside the web request.
Staging Is a Recovery Test, Not a Copy of Production
A robust staging environment is not created simply by adding another server. It proves that code, configuration, data and files can be restored in a controlled manner – without bringing along production access, real notifications or unnoticed copies of personal data.
A Component Needs a Contract, Not Just a Preview
A living style guide only becomes an architectural tool when components use the same templates, defined inputs and verifiable exports as the application. For Fluid, this creates a contract that holds design, implementation and testing together.
The dry run must be able to fail
A simulation is only valuable if it reflects the same contracts, states and error paths as the real integration. For TYPO3 projects, this results in a clear architecture: domain core, interchangeable adapters, controlled live tests and visible approvals.
AI Needs a Job Status, Not a Loading Indicator
Generative AI rarely fits the classic request-and-response cycle. A robust background process makes runtime, errors, retries and human decisions visible – improving both architecture and user experience.