chore: update dependencies and client timeouts

.agent/SOPs/readme.md

@@ -0,0 +1,124 @@
+# 📝 Standard Operating Procedures (SOPs)
+
+> **Learn from experience. Document solutions. Prevent repeated mistakes.**
+
+This folder contains Standard Operating Procedures — step-by-step guides for tasks that have been successfully completed or issues that have been resolved.
+
+---
+
+## Purpose
+
+When the agent (or you) solves a complex problem or successfully integrates a service:
+
+1. **Document the solution** — Create an SOP immediately
+2. **Include pitfalls** — Note what went wrong and how it was fixed
+3. **Make it reusable** — Future work on similar tasks should reference this
+
+---
+
+## How to Create a New SOP
+
+Ask the agent:
+
+> "Generate SOP for [task/integration name]"
+
+Or manually create using the template below.
+
+---
+
+## SOP Template
+
+```markdown
+# SOP: [Task/Integration Name]
+
+## Overview
+Brief description of what this SOP covers.
+
+## Prerequisites
+- List of required tools, access, or knowledge
+- Environment setup needed
+
+## Step-by-Step Procedure
+
+### Step 1: [Step Title]
+Description of what to do.
+
+```bash
+# Commands if applicable
+example command
+```
+
+### Step 2: [Step Title]
+Continue with next steps...
+
+## Common Pitfalls
+
+### ⚠️ [Pitfall Name]
+**Problem:** What goes wrong  
+**Solution:** How to fix it
+
+### ⚠️ [Another Pitfall]
+**Problem:** What goes wrong  
+**Solution:** How to fix it
+
+## Verification
+How to confirm the task was successful.
+
+## References
+- Link to relevant documentation
+- Related code files
+
+---
+
+**Created:** YYYY-MM-DD  
+**Last Updated:** YYYY-MM-DD  
+**Author:** [Name/Agent]
+```
+
+---
+
+## SOP Categories
+
+Organize SOPs by category:
+
+```
+.agent/SOPs/
+├── readme.md (this file)
+├── integration/
+│   └── ogmios-connection.md
+├── release/
+│   └── maven-publish.md
+└── debugging/
+    └── websocket-timeouts.md
+```
+
+---
+
+## Index of SOPs
+
+> Update this section as new SOPs are added.
+
+| Category | SOP Name | Description | Date |
+|----------|----------|-------------|------|
+
+---
+
+## When to Create an SOP
+
+Create an SOP when:
+
+- ✅ A complex integration is successfully completed
+- ✅ A tricky bug is finally resolved
+- ✅ A deployment issue is troubleshot
+- ✅ A new service or tool is set up for the first time
+- ✅ The same question/issue comes up multiple times
+
+---
+
+## Best Practices
+
+1. **Be specific** — Include exact commands, file paths, and configuration
+2. **Include context** — Explain *why* steps are necessary, not just *what*
+3. **Test the SOP** — Verify steps work by following them yourself
+4. **Keep updated** — Revise when processes change
+5. **Link related SOPs** — Cross-reference when tasks are related

.agent/readme.md

@@ -0,0 +1,147 @@
+# 📚 Kogmios Agent Documentation Index
+
+> **For AI Agents:** Read this file first to understand available documentation and when to reference each resource.
+
+This folder contains documentation for assisting with development on the Kogmios project (Kotlin implementation of an Ogmios client). Use this index to quickly navigate to the relevant documentation for your current task.
+
+---
+
+## 🗺️ Quick Navigation
+
+| Folder | Purpose | When to Read |
+|--------|---------|--------------|
+| [`/system`](./system/) | Architecture, build/publish, design patterns | **First**, for any architectural decisions or understanding system design |
+| [`/task`](./task/) | PRDs and implementation plans history | When implementing new features similar to past work |
+| [`/SOPs`](./SOPs/) | Standard Operating Procedures | When encountering known issues or following established patterns |
+| [`/workflows`](./workflows/) | Step-by-step development workflows | When executing specific development tasks |
+
+---
+
+## 📁 Folder Details
+
+### `/system` — Architecture & Patterns
+
+**The source of truth for major architectural decisions.**
+
+Read these files to understand:
+- Overall system architecture and component relationships
+- Client/protocol layout and data models
+- Build, publish, and versioning expectations
+- Integration patterns with Ogmios/Cardano
+
+Files:
+- `architecture.md` — System overview, modules, protocols, data flow
+
+---
+
+### `/task` — Implementation History
+
+**Successful PRDs and implementation plans for reference.**
+
+Before implementing a feature:
+1. Check if a similar feature was implemented before
+2. Use past plans as templates for consistency
+3. Follow established patterns from successful implementations
+
+This folder uses subdirectories per major feature/task.
+
+---
+
+### `/SOPs` — Standard Operating Procedures
+
+**Learnings from resolved issues and best practices.**
+
+When an issue is resolved or a complex integration succeeds:
+1. Document the step-by-step solution
+2. Include common pitfalls and how to avoid them
+3. Reference related code or configuration
+
+**To create a new SOP**, ask the agent:
+> "Generate SOP for [task/integration name]"
+
+---
+
+### `/workflows` — Development Workflows
+
+**Step-by-step guides for common development tasks.**
+
+Available workflows:
+
+| Workflow | Description | Trigger |
+|----------|-------------|---------|
+| [`build.md`](./workflows/build.md) | Build project | `/build` |
+| [`test.md`](./workflows/test.md) | Run tests | `/test` |
+| [`backend_dependencies.md`](./workflows/backend_dependencies.md) | Check dependency updates | `/backend_dependencies` |
+| [`update-doc.md`](./workflows/update-doc.md) | Update documentation | `/update-doc` |
+
+---
+
+## 🏗️ Project Overview
+
+**Kogmios** is a Kotlin client implementation for the Ogmios WebSocket interface. It wraps Ogmios JSON-WSP messages into typed models and uses coroutines for async operations.
+
+### Technology Stack
+
+| Layer | Technology | Notes |
+|-------|------------|-------|
+| **Language** | Kotlin 2.x on Java 21 | Kotlin JVM library |
+| **Networking** | Ktor client (CIO + websockets) | WebSocket communication |
+| **Serialization** | kotlinx-serialization | JSON-WSP payloads |
+| **Concurrency** | Kotlin coroutines | Suspended client calls |
+| **Logging** | Logback, Commons Logging | Client logging |
+| **Build** | Gradle (Kotlin DSL) | Single module |
+
+### Module Overview
+
+```
+kogmios
+└── src/
+    ├── main/kotlin/io/newm/kogmios/...
+    └── test/kotlin/io/newm/kogmios/...
+```
+
+### Client Types
+
+Kogmios exposes four logical clients:
+- `StateQuery`
+- `TxSubmit`
+- `TxMonitor`
+- `ChainSync`
+
+---
+
+## ⚡ Quick Commands
+
+### Build & Test
+```bash
+# Build
+./gradlew build
+
+# Run tests
+./gradlew test
+```
+
+### Code Quality
+```bash
+# Lint check
+./gradlew ktlintCheck
+
+# Auto-fix formatting
+./gradlew ktlintFormat
+```
+
+---
+
+## 🧩 Skills
+
+**Skills are reusable instructions the agent can load with the `skill` tool.**
+
+Current status:
+- `git-commit-formatter` — Formats git commit messages to Conventional Commits when asked to commit or draft commit messages. See `.agent/skills/git-commit-formatter/SKILL.md`.
+
+If skills are added, list them here with a short description and usage guidance.
+
+## 🔐 Security Notes
+
+- Never commit secrets or API keys
+- Avoid checking in credentials for Ogmios nodes

.agent/skills/git-commit-formatter/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: git-commit-formatter
+description: Formats git commit messages according to Conventional Commits specification. Use this when the user asks to commit changes or write a commit message.
+---
+
+# Git Commit Formatter Skill
+
+When writing a git commit message, you MUST follow the Conventional Commits specification.
+
+## Format
+`<type>[optional scope]: <description>`
+
+## Allowed Types
+- **feat**: A new feature
+- **fix**: A bug fix
+- **docs**: Documentation only changes
+- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
+- **refactor**: A code change that neither fixes a bug nor adds a feature
+- **perf**: A code change that improves performance
+- **test**: Adding missing tests or correcting existing tests
+- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation
+
+## Instructions
+1. Analyze the changes to determine the primary `type`.
+2. Identify the `scope` if applicable (e.g., specific component or file).
+3. Write a concise `description` in imperative mood (e.g., "add feature" not "added feature").
+4. If there are breaking changes, add a footer starting with `BREAKING CHANGE:`.
+
+## Example
+`feat(auth): implement login with google`