Flopsstuff · Fl0p · May 24, 2026 · May 24, 2026 · May 24, 2026 · May 24, 2026
diff --git a/src/content/ccui.md b/src/content/ccui.md
@@ -0,0 +1,38 @@
+## Overview
+
+**ccui** is the project page entry for CloudCLI (also described as Claude Code UI), an open-source web interface for running and managing CLI coding agents from a browser on desktop or mobile. The repository is maintained as a fork of `siteboon/claudecodeui`, with additional deployment and provider integrations documented in its README. The same codebase powers local self-hosted usage and the hosted CloudCLI offering linked from `cloudcli.ai`.
+
+## Why it exists
+
+Terminal-first tools like Claude Code, Cursor CLI, Codex, and Gemini CLI are powerful, but they are not ideal when you need remote or mobile access, quick session switching, or a shared visual workflow. CloudCLI exists to make those CLI sessions easier to operate through a web UI: discover and resume sessions, work with files and Git, and manage tool settings from one place.
+
+The project also targets self-hosting and portability. The README emphasizes Docker-first setup, optional cloud tunnel access, and support for AWS Bedrock authentication, so users can run it in local or enterprise-style environments without changing the core UI workflow.
+
+## How it works
+
+CloudCLI combines a React/Vite frontend with a Node.js backend. At a high level:
+
+1. The backend (`server/`) starts and manages agent CLIs, session state, and integrations.
+2. The frontend (`src/`) renders the chat/workspace UI, project and session navigation, file/Git views, and settings.
+3. Packaging options expose the same app in different ways: local npm (`npx @cloudcli-ai/cloudcli`), Docker Compose for self-hosting, or the managed cloud service.
+
+The repository also documents plugin support, where additional tabs/services can be installed to extend the core UI behavior.
+
+## Technical details
+
+| Aspect | Detail |
+| --- | --- |
+| Upstream base | Fork of `siteboon/claudecodeui` |
+| Runtime | Node.js app with React 18 + Vite frontend |
+| Package | `@cloudcli-ai/cloudcli` |
+| CLI coverage (documented) | Claude Code, Cursor CLI, Codex, Gemini CLI |
+| Deployment options | npm (`npx`), Docker Compose, managed CloudCLI |
+| Notable integrations | AWS Bedrock mode, Cloudflare tunnel guidance, plugin system |
+| License | MIT (`LICENSE` in repo) |
+
+## Links
+
+- [Repository](https://github.com/Flopsstuff/ccui)
+- [README](https://github.com/Flopsstuff/ccui/blob/main/README.md)
+- [Live site](https://cloudcli.ai)
+- [Upstream project](https://github.com/siteboon/claudecodeui)
diff --git a/src/content/chaiba.md b/src/content/chaiba.md
@@ -0,0 +1,36 @@
+## Overview
+
+**chaiba** (Chess AI Battle Arena) is a React-based web platform designed to host and visualize chess matches between various artificial intelligence models. It provides a clean, real-time interface for observing how different Large Language Models (LLMs) compete in a game of chess, from strategic opening moves to the final checkmate.
+
+## Why it exists
+
+With the rise of LLMs, many researchers and enthusiasts are curious about their reasoning and strategic capabilities. While there are many ways to prompt an LLM to play chess, there wasn't a standardized, easy-to-use arena for direct comparison. 
+
+**chaiba** fills this gap by providing a unified environment where users can benchmark and observe models from different providers side-by-side. By using a single OpenRouter integration, it eliminates the need to manage multiple API clients or complex prompting setups for each model being tested.
+
+## How it works
+
+1. **Model Connectivity** — The application uses the Vercel AI SDK to connect to a vast array of models via OpenRouter. This allows it to support models from OpenAI, Anthropic, Google, and more.
+2. **Game Logic** — It maintains the chess state client-side, managing move validation and ensuring the models adhere to standard chess rules.
+3. **Real-Time Visualization** — As models generate moves, the arena updates the board in real-time, allowing users to watch the strategic battle unfold.
+4. **Configuration** — Users provide their own OpenRouter API key in the settings, giving them full control over which models they pit against each other and managing their own costs.
+
+## Technical details
+
+| Aspect          | Detail                                                |
+| --------------- | ----------------------------------------------------- |
+| Framework       | React 19 + Vite                                       |
+| Language        | TypeScript                                            |
+| AI Integration  | Vercel AI SDK + OpenRouter                            |
+| Routing         | React Router v7 (HashRouter for GitHub Pages)         |
+| Hosting         | GitHub Pages                                          |
+| Testing         | Vitest                                                |
+
+The project is built as a Single Page Application (SPA), ensuring all game logic and AI interactions happen directly in the user's browser. It leverages modern React features and strict TypeScript to maintain a robust and maintainable codebase.
+
+## Links
+
+- [Repository](https://github.com/Flopsstuff/chaiba)
+- [Live Demo](https://flopsstuff.github.io/chaiba/)
+- [OpenRouter](https://openrouter.ai/)
+- [Vercel AI SDK](https://sdk.vercel.ai/docs)
diff --git a/src/content/ksef-docs.md b/src/content/ksef-docs.md
@@ -0,0 +1,35 @@
+## Overview
+
+`ksef-docs` is a maintained translation mirror of documentation for Poland's KSeF 2.0 e-invoicing system. The project publishes the original Polish docs together with translated versions in English, Russian, and Ukrainian, then serves everything as a static VitePress site. Instead of being a one-off translation dump, it is structured as a repeatable sync-and-translate pipeline that can keep pace with upstream updates.
+
+## Why it exists
+
+The upstream KSeF documentation is primarily Polish, which creates friction for developers and integration teams working in other languages. `ksef-docs` exists to lower that barrier by keeping non-Polish docs continuously available and close to the current upstream state.
+
+It also solves maintenance pain: upstream docs and OpenAPI content change over time, and manually re-translating every update across multiple languages is hard to sustain. This repo turns that work into an automated workflow with tracked translation state and scheduled refreshes.
+
+## How it works
+
+1. The upstream documentation is tracked via the `original/` git submodule (`CIRFMF/ksef-docs`).
+2. Sync scripts detect changed upstream files and identify what is outdated.
+3. Translation scripts call a configured LLM provider (Anthropic, OpenRouter, or Bedrock) to translate docs and OpenAPI while preserving markdown structure.
+4. Per-language outputs are written under `translations/<lang>/`, and `translation.lock.json` records source commit/hash metadata.
+5. Build scripts prepare a VitePress-ready tree in `site/<lang>/`, normalize markdown/frontmatter, copy assets, and generate an API reference page.
+6. GitHub Actions deploy the built site to GitHub Pages, and a scheduled workflow runs translation updates on Mondays and Thursdays at 08:00 UTC.
+
+## Technical details
+
+| Aspect | Detail |
+| --- | --- |
+| Stack | TypeScript + Node scripts, VitePress |
+| Package tooling | Yarn 4 (`packageManager: yarn@4.11.0`) |
+| Core deps | `openai`, `@anthropic-ai/sdk`, `@anthropic-ai/bedrock-sdk`, `gray-matter`, `dotenv` |
+| Source model | Upstream docs via git submodule (`original/`) |
+| Output | Static multilingual docs site on GitHub Pages |
+| License | MIT |
+
+## Links
+
+- [Repository](https://github.com/Flopsstuff/ksef-docs)
+- [Live site](https://flopsstuff.github.io/ksef-docs/)
+- [Upstream source docs (CIRFMF/ksef-docs)](https://github.com/CIRFMF/ksef-docs)
diff --git a/src/content/soulgrep.md b/src/content/soulgrep.md
@@ -0,0 +1,38 @@
+## Overview
+
+**soulgrep** is an AI-powered analyzer for chat history, specifically designed to infer psychological profiles (psychotypes) from Telegram exports. It transforms thousands of fragmented messages into a structured behavioral portrait, allowing users to "grep the human signal" from the noise of digital communication.
+
+## Why it exists
+
+Modern chat logs are voluminous and messy, making it difficult to maintain a high-level understanding of a person's communication style or personality traits over time. While LLMs are capable of this analysis, most tools require uploading sensitive, private chat logs to a third-party cloud.
+
+soulgrep was built with a **privacy-first** mandate. It performs all data parsing and chunking locally in the browser, ensuring that raw chat logs never leave the user's machine. Data is only sent to the user's chosen LLM provider (OpenAI, Anthropic, or OpenRouter) using their own API keys, providing full control over data sovereignty.
+
+## How it works
+
+The analysis workflow is divided into three distinct phases:
+
+1.  **Ingestion & Parsing** — The user uploads a Telegram `result.json` export. A background Web Worker parses the file locally to extract message history and build a "persona corpus" for the target speaker.
+2.  **Signal Extraction** — The application splits the corpus into manageable chunks and executes parallel LLM calls. Each call identifies specific behavioral signals, linguistic patterns, and psychological markers within that chunk.
+3.  **Synthesis** — A final LLM pass aggregates the extracted signals into a cohesive psychological profile, covering communication style, cognitive patterns, and interpersonal dynamics.
+
+The resulting "psychotype" can be explored in the dashboard or exported as a structured JSON/Markdown report.
+
+## Technical details
+
+| Aspect       | Detail                                                        |
+| ------------ | ------------------------------------------------------------- |
+| Frontend     | React 19, TypeScript, Vite 8                                  |
+| Styling      | Tailwind CSS v4                                               |
+| Routing      | React Router v7 (data-router mode)                            |
+| Processing   | Browser Web Workers for non-blocking local parsing            |
+| Deployment   | Cloudflare Workers (SPA)                                      |
+| Tooling      | Biome (linting/formatting), Vitest (testing)                  |
+
+The application is a pure SPA, leveraging the browser's capabilities to handle large JSON exports without a backend, which reinforces its privacy-centric design.
+
+## Links
+
+- [Repository](https://github.com/Flopsstuff/soulgrep)
+- [Live Application](https://soulgrep.aignite.pl)
+- [Telegram: Exporting Your Data](https://telegram.org/blog/export-and-more)
diff --git a/src/content/wetty.md b/src/content/wetty.md
@@ -0,0 +1,42 @@
+## Overview
+
+**WeTTY** (Web + TTY) exposes a terminal session in a browser over HTTP/HTTPS. It gives operators and developers a web URL for shell access without requiring users to install a local SSH client. The project is positioned as a modern replacement for older browser-terminal tools, with terminal emulation handled by xterm.js and real-time transport handled over WebSockets.
+
+Out of the box, WeTTY serves a web UI (default path `/wetty`) and starts a shell session behind it. In common deployments it runs as a Node.js service directly or as a Docker container behind a reverse proxy.
+
+## Why it exists
+
+Many teams need terminal access in environments where installing or using native SSH clients is inconvenient: managed lab machines, browser-only devices, onboarding sandboxes, and internal support workflows. WeTTY exists to bridge that gap by putting a familiar terminal experience in the browser while still connecting to standard shell/SSH backends.
+
+The project also targets responsiveness and compatibility. Instead of polling or Ajax-style terminal updates, it uses Socket.IO/WebSocket messaging, and instead of a minimal text area it uses xterm.js for full terminal emulation behavior.
+
+## How it works
+
+At startup, the CLI entry point parses configuration and flags (for host/port, SSH target, SSL files, command override, and auth-related options), then starts the server.
+
+1. The server layer runs on Express, adds metrics/logging middleware, and exposes the web client.
+2. A Socket.IO connection is opened per browser session.
+3. On connect, WeTTY resolves the command to run (for example `/bin/login` when running as root, or `ssh` to a configured host/user).
+4. The backend spawns a PTY-backed process and streams terminal I/O through the socket.
+5. The browser client renders output with xterm.js and sends keyboard input/resize events back to the server.
+
+This keeps the architecture simple: browser terminal frontend + WebSocket bridge + spawned shell/SSH process.
+
+## Technical details
+
+| Aspect | Detail |
+| --- | --- |
+| Runtime | Node.js (`>=18`) |
+| Language | TypeScript (compiled to `build/`) |
+| Server stack | Express + Socket.IO |
+| Terminal emulation | `@xterm/xterm` |
+| Process bridge | `node-pty` |
+| Packaging | npm package (`wetty`) and Docker image (`wettyoss/wetty`) |
+| License | MIT |
+
+## Links
+
+- [Repository](https://github.com/Flopsstuff/wetty)
+- [Live docs/site](https://butlerx.github.io/wetty)
+- [Flags reference](https://butlerx.github.io/wetty/flags)
+- [Docker image](https://hub.docker.com/r/wettyoss/wetty)