FEAT: Implement Docker containerization and deployment guide

docs/deployment.org

@@ -0,0 +1,36 @@
+#+TITLE: Deployment Guide: Containerized Org-Agent
+#+AUTHOR: Amr
+#+DATE: [2026-04-11 Sat]
+#+FILETAGS: :deployment:docker:infrastructure:
+
+* Overview
+The ~org-agent~ is designed to run within a Docker container to ensure system dependencies (SBCL, Quicklisp, signal-cli) are perfectly matched across different host environments.
+
+* Prerequisites
+- Docker Engine
+- Docker Compose
+- A valid ~.env~ file in the ~projects/org-agent/~ directory (refer to ~.env.example~).
+
+* Quick Start
+** 1. Build and Start
+From the ~projects/org-agent/~ directory:
+#+begin_src bash
+docker-compose up --build -d
+#+end_src
+
+** 2. Check Logs
+#+begin_src bash
+docker-compose logs -f
+#+end_src
+
+* Volume Mapping
+The ~docker-compose.yml~ file automatically mounts your host's ~memex~ directory to ~/memex~ inside the container. This allows the agent to:
+1. Read/Write to your Zettelkasten and GTD files.
+2. Maintain its local state (Object Store, snapshots).
+
+* Troubleshooting
+** signal-cli Identity
+If using the Signal gateway, ensure you have registered your number via the host's ~signal-cli~ or within the container. The state is preserved in the ~signal-state~ Docker volume.
+
+** Re-loading Skills
+The container pre-caches dependencies during the build. If you modify core Lisp logic, you must rebuild the image (~--build~). If you only modify ~.org~ skills in your memex, the agent can reload them dynamically if they are part of the startup scan.

docs/rca/rca-infrastructure-docker.org

@@ -0,0 +1,30 @@
+#+TITLE: Root Cause Analysis: Containerized Infrastructure (Docker)
+#+DATE: 2026-04-11
+#+FILETAGS: :rca:docker:deployment:infrastructure:psf:
+
+* Executive Summary
+Standardized the `org-agent` execution environment by creating a production-grade Docker infrastructure. This ensures that all system dependencies, including the Lisp runtime and external binaries like `signal-cli`, are locked down and portable.
+
+* 1. Architectural Intent: The "Clean Room" Model
+** Problem
+The `org-agent` was relying on host-local binaries (`sbcl`, `signal-cli`) and manually configured Quicklisp dists. This made deployment to other environments (e.g., a VPS or a Sovereign Home Server) fragile and prone to version drift.
+** Solution
+1. **Dockerfile:** Created a multi-step build process that installs Debian Bookworm, SBCL, Java, and `signal-cli 0.14.0`.
+2. **Pre-Caching:** The build process triggers a `ql:quickload` of the `:org-agent` system, ensuring all Lisp dependencies are pre-downloaded and stored in the image layer, drastically reducing startup time.
+3. **Compose Orchestration:** Standardized the runtime via `docker-compose.yml`, which handles volume mounting of the user's `memex` directory and injection of `.env` secrets.
+
+* 2. Volume Mapping & Persistence
+** Strategy
+To maintain the "Sovereign" mandate, the agent's code is isolated, but its memory (the `memex`) remains on the host. 
+- **Mapping:** `../..` (host) -> `/memex` (container).
+- **State:** Created a named Docker volume `signal-state` to ensure that `signal-cli` identities and cryptographic keys survive container restarts and image updates.
+
+* 3. Alignment with PSF Mandates
+** Evolutionary Completion
+By moving to Docker, we have achieved "Evolutionary Completion" for the deployment track. The system is no longer a collection of scripts; it is a deployable appliance.
+** Documentation
+A new `Deployment Guide` was added to `docs/deployment.org` to ensure standard operating procedures are preserved.
+
+* 4. Permanent Learnings
+- **Lisp Build Layers:** Always push the system to the ASDF registry and quickload during Docker build to bake dependencies into the image.
+- **Compose Locality:** Placing the `docker-compose.yml` inside the `projects/org-agent/` folder keeps infrastructure code close to the implementation logic.