feat: persist settings and enrich conversation context

agents.md

@@ -19,20 +19,11 @@ Refactor code to improve maintainability, testability, and clarity. Break down l
 - **Zod Validation**: Use `zod` (already in deps) to validate external data (config files, API responses).
 - **Async/Await**: properly handle promises. Use `p-queue` or `p-retry` for rate-limited operations.
 
-### 4. Test-Driven Development (TDD) — REQUIRED
-All new functionality and bug fixes MUST follow the red-green-refactor cycle. This is non-negotiable.
-
-- **Red**: Write a failing test FIRST that describes the desired behavior. Run it and confirm it fails for the expected reason.
-- **Green**: Write the minimum production code needed to make the test pass. No extra features, no speculative abstractions.
-- **Refactor**: With tests green, clean up implementation and tests. Re-run the suite after each change.
-
-**Rules**:
-- Never commit production code without an accompanying test that fails without it.
+### 4. Testing
+- TDD is not required. Agents may implement changes before writing or updating tests.
+- Add or update tests when they provide useful coverage for new functionality or bug fixes.
 - Tests live in `tests/` (mirroring `src/` structure) and run via `vitest` (`npm test`).
-- Use dependency injection so collaborators (DB, HTTP, browser, clock) can be faked — do not mock what you don't own; wrap third-party APIs in a thin interface and fake the interface.
 - Prefer behavior-focused tests (inputs → outputs / observable side effects) over tests that pin internal structure.
-- Bug fixes start with a regression test that reproduces the bug.
-- If a change is genuinely untestable (e.g. a one-line config tweak), state that explicitly in the PR/commit rather than skipping silently.
 
 ### 5. Project Specifics
 - **Tech Stack**: Node.js, TypeScript, Playwright, Express, SQLite, Vitest.
@@ -45,10 +36,10 @@ All new functionality and bug fixes MUST follow the red-green-refactor cycle. Th
 
 ## Workflow for Agents
 1. **Analyze**: Before writing code, read the file and understand the context.
-2. **Plan**: Identify what needs to change. Check if the change violates SRP. Identify the test(s) that will drive the change.
-3. **Write failing test (Red)**: Add a vitest spec that captures the new behavior or reproduces the bug. Run `npm test` and confirm it fails for the right reason.
-4. **Implement (Green)**: Write the smallest change that makes the test pass. Create new small files when SRP calls for it.
-5. **Refactor**: Tidy the implementation and the test with the suite green. Re-run tests after each refactor step.
-6. **Verify**: Ensure the full suite passes (`npm test`) and types check (`npm run build` or `tsc --noEmit`).
+2. **Plan**: Identify what needs to change and check if the change violates SRP.
+3. **Implement**: Make the scoped change. Create new small files when SRP calls for it.
+4. **Test**: Add or update useful tests as appropriate for the change.
+5. **Refactor**: Tidy the implementation and tests while preserving behavior.
+6. **Verify**: Run the relevant tests and type checks (`npm run build` or `tsc --noEmit`) in proportion to the change.
 
-You must use the dokploy credentials in .env for access to dokploy
+You must use the dokploy credentials in .env for access to dokploy