标签：#devchallenge

This is a submission for the Hermes Agent Challenge TL;DR — Type a one-line bill topic. Twenty-five Hermes agents (1 Speaker, 19 ministries, 5 parties) run a full Polish legislative session in 2 minutes. Vote tally, social impact, party tweets — and a side-by-side "current law vs proposed amendment" with every clause cited to a real statute. Built on delegate_task for parallel ministry consultation. 🌐 Live: https://web-production-53027.up.railway.app/ 🎥 Walkthrough: https://www.loom.com/share/92cdac7da31c471088a4e569b0cfe1ed 📦 Repo: https://github.com/monsad/ai-politics (MIT) What I Built Watch a politician debate a new tax law on TV. They argue whether it's fair, whether it'll work, whether the other side is lying. Nobody ever shows you the diff — which paragraph of which statute actually changes, and from what to what. The conversation is theatre on top of an invisible legal document. So I built the theatre AND the legal document. Virtual Parliament is a multi-agent simulation of the Polish Sejm. You type something like "four-day work week" or "flat income tax" , and 25 Hermes agents run a full legislative session: 🎯 Marszałek (Speaker) — the orchestrator. Classifies the topic. Picks 2–3 ministries via delegate_task in parallel . Reads their findings. Routes the bill to a party debate. 🏛️ 19 ministry experts — Finance, Climate, Labour & Social Policy, Justice, … Each returns a structured analysis: legal finding · budget impact · top 3 risks · recommendation . Every claim cites a real statute via PageIndex RAG. 🗳️ 5 party agents — KO, PiS, TD, Konfederacja, Lewica. Each one carries the real party's seat count (157, 194, 65, 18, 26 — totalling 460), policy positions and rhetorical style. First reading. Second reading with rebuttals. 📊 Vote — weighted by seats. >230 passes. 📜 Draft bill — produced with explicit "Article 129 §1 of the Labour Code **is amended to read …" diffs against current law. The frontend surfaces the diff as a Current law vs proposed change panel

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built pq — jq for Parquet. A 50 MB Rust single binary that wraps DuckDB's query engine in a jq-style expression DSL, optimized for terminal one-liners and unix pipes. $ pq sales.parquet 'group_by .country | sum .revenue | top 3 by sum_revenue' ┌─────────┬─────────────┐ │ country ┆ sum_revenue │ ╞═════════╪═════════════╡ │ US ┆ 19065.00 │ │ FR ┆ 999.99 │ │ DE ┆ 312.00 │ └─────────┴─────────────┘ Where it started. I work in adtech. I look at parquet files dozens of times a day — campaign deliveries, partner exports, audience snapshots. Every existing option was painful: Tool Pain pyarrow / pandas 5-second cold start, 200 MB virtualenv parquet-tools JVM, slow, no query support pqrs Inspector only — can't filter or project duckdb CLI Great engine, but SELECT email FROM 'file.parquet' WHERE country='US' is too verbose to type 50 times a day Spark Are you serious pq is the tool I actually want — single binary, no JVM, no Python, jq-style syntax for piping into the rest of the unix toolbox. It's been my default cat for parquet since v0.5. Demo Repo : github.com/thehwang/parq Latest release : v0.14.0 (this submission) Install : brew install thehwang/parq/pq Tutorial : doc/tutorial.md — 30-minute hands-on walkthrough A taste of what shipped in v0.14: # Streaming JSON output (was the only buffered format until v0.14) $ pq big.parquet '.id, .country' -o json | head -c 200 # returns instantly even on a 40 GB file # Schema-drift gate for CI $ pq diff baseline.parquet candidate.parquet # Schema diff - a: ` baseline.parquet ` - b: ` candidate.parquet ` ## Added (1) | column | type | nullable | |-----------|---------|----------| | ` country ` | VARCHAR | yes | $ echo $? 1 # exits non-zero on drift, slots into CI without scripting And the new TUI Explain panel — press capital E for EXPLAIN ANALYZE , get row-group pruning per scan (this is exactly the panel you see on the cover image at the top of this post): Expla

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent Hermes Agent...

A $0 multi-model decision agent: three LLMs debate, Hermes judges, and it learns who to trust.

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I revisited my personal website and decided to turn it into a more complete and polished portfolio. The project originally started as a simple personal website hosted on GitHub Pages. While it was functional, many planned features and improvements were never completed. For this challenge, I am working on improving the mobile experience, adding dark mode support, enhancing the Projects section, improving SEO, fixing existing issues, and making the website more interactive and professional. My goal is to transform an unfinished personal website into a modern portfolio that better represents my work, skills, and projects. Demo Live Website https://ehsankahrizi.github.io/ GitHub Repository https://github.com/Ehsankahrizi/Ehsankahrizi.github.io Current Status This project is currently being improved as part of the GitHub Finish-Up-A-Thon Challenge. Planned improvements include: Better mobile responsiveness Dark mode support Enhanced Projects section Improved SEO More interactive user experience Better website performance Additional pages and content Fixing existing usability issues The Comeback Story When I returned to this project, I realized that many ideas I originally had for the website were still unfinished. Although the website was online, it still had several limitations: The mobile experience needed improvement. Dark mode was not available. The Projects section was incomplete. The contact functionality needed attention. SEO optimization was missing. The website relied on a mostly single-page structure. User interactions were limited. Performance could be improved. Instead of starting a new project, I decided to revisit this existing one and finally complete the improvements that had been postponed. This challenge provided the perfect opportunity to continue development, clean up the codebase, improve the user experience, and turn the website into something I can confidently share with ot

This is a submission for the Hermes Agent Challenge . I have been playing with different AI agents for a while now. Most of them feel like clever chatbots that forget everything the moment the conversation ends. Then I tried Hermes Agent from Nous Research a few weeks back. It actually feels different. It grows with you. That stuck with me. What Hermes Agent is Hermes is an open-source autonomous agent that runs on your own server or VPS. It is not locked to one IDE or one API. You install it once, pick any model you like, and it starts building its own memory and skills over time. The big idea is a built-in learning loop. When it solves something useful, it can create a reusable skill in Markdown, improve it later, and pull it back when needed. It also keeps persistent memory across sessions so it slowly builds a picture of how you work and what your projects look like. I set it up on a cheap VPS with a simple curl command. The installer is straightforward. After that I ran hermes setup and connected it to a model I already had access to. Within minutes I could chat with it from Telegram while it worked in the background on the server. That alone felt freeing. My experience so far I started simple. I asked it to monitor a few GitHub repos and send me a daily summary. It remembered the context from previous days without me repeating instructions. Over a week it created a couple of small skills on its own for formatting those reports nicely. I also used it for research tasks. It can search the web, browse pages, and chain steps together. What surprised me was how it handled follow-ups. Instead of starting fresh each time, it referred back to earlier parts of our conversation. That made longer projects feel more natural. The multi-platform support is practical. I switch between CLI on my laptop and Telegram on my phone. The agent just continues wherever I left it. Why it matters Most agent frameworks still feel stateless. You get good results in the moment but lose th

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built SecAPI is a local-first, zero-trust CLI utility and key manager designed to make code security the easiest developer path. Exposing secrets (like Stripe, OpenAI, or AWS keys) in repository files is one of the most common causes of credential leaks. Often, developers resort to plaintext .env files that can be accidentally staged and pushed, or struggle with complex vault set-ups. SecAPI solves this with a seamless three-step command line workflow: Scans codebases for exposed API keys using fast regex rules or advanced AI analysis. Vaults secrets locally using strong AES-256 encryption derived via PBKDF2-HMAC (completely offline). Replaces raw hardcoded strings in code with secure, runtime references ( load_key("key_name") )—preserving variable names, indentation, and comments. It means we can keep our code secure, separate environments easily, and prevent pushes with unencrypted credentials—all without relying on cloud-based vault hosts. Demo Interactive Web Showcase : secapi.netlify.app GitHub Repository : github.com/BinayakJha/SecAPI The Scrolling CLI Showcase in Action Check out the interactive scrollytelling page on secapi.netlify.app to see the simulator type out and execute the CLI commands (scanning, setting up vaults, applying smart code rewrites, checking the status board, and running the git pre-commit hook) in real-time as you scroll! The Comeback Story Where It Started SecAPI was an abandoned CLI prototype. It was un-installable due to file packaging typos, suffered from weak vault security (a custom padding scheme instead of a standard key derivation function), had no recovery options if the master password was lost, and used a basic console print command to list keys. Furthermore, the AI scanner relied on outdated OpenAI package versions, creating environment conflicts. What I Changed, Fixed, and Added I gave the project a complete, ground-up overhaul to turn it into a premium,

This is a submission for the Hermes Agent Challenge What I Built Onyx is an autonomous infrastructure operator running 24/7 on my droplet. He manages my entire stack: 6 Next.js deployments, 5 Docker containers, a Minecraft server, fail2ban, Nginx, and UFW. He also helps me write my undergraduate thesis. The difference from every other "AI agent" project I've seen: Onyx doesn't wait for commands. He surfaces problems, patches vulnerabilities, and pushes work forward on his own. When I wake up, there's a session log waiting for me, not a to-do list. The core idea: graduate an AI agent from assistant to operator . A chatbot with tools bolted on doesn't cut it. I wanted something that runs infrastructure while I'm eating dinner, asleep, or in class. Demo Onyx operates through Discord. A normal week: 🔴 3 AM — gateway process failure, no wake-up required A gateway process had a stale PID. Onyx detected it, diagnosed the root cause, restarted it cleanly, and wrote a session log. I found out in the morning. Zero human intervention, zero downtime. 🟡 Dinner — 9 CVEs found across Docker containers While I was eating, Onyx ran a routine audit, found 9 CVEs, rebuilt 3 container images from fresh base images, patched Python dependencies, hardened fail2ban (ban time: 600s to 24 hours), and verified every container came back healthy. 🟢 "Fix it" — two words, full tunneling deployment My friends in Indonesia couldn't connect to the Minecraft server because their ISPs use carrier-grade NAT. I sent Onyx "fix it." He researched solutions, selected playit.gg, installed the tunneling agent, configured a systemd service, and optimized TCP keepalive parameters. All autonomous. 🧠 Accountability loop Onyx noticed I kept asking for things but not acting on the output. He surfaced it: "You keep opening new loops and not closing them." He was right. Now when I open a loop, Onyx tracks it until it's closed or explicitly shelved. 📚 Thesis research partner I'm finishing my undergraduate thesis on e

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built GlowStore — a full-stack MERN e-commerce store (React + Redux + Express + MongoDB). Back in 2023 I built this as my university Web Engineering final project. I ran out of time, handed in what I had, and never touched it again. When I reopened it for this challenge I found something funny: the backend was basically finished — JWT auth, products, orders, reviews, search — but the React frontend never actually talked to it. It was a good-looking shell with fake logic bolted on. So "finishing it" meant connecting the two halves and making it a real store you can actually shop in. Repo: https://github.com/hashaam-011/Web-Engineering Demo Before — the entire app was just a fake login screen. Typing anything (or nothing) and clicking "Log in" flipped a boolean and "logged you in": After — a working storefront with products from the database: A real product detail page (was literally <h1>DetailsPages</h1> before): You can run it yourself in two terminals (no database setup needed — it boots an in-memory MongoDB and seeds itself): cd backend && npm install && npm start # http://localhost:4000 npm install && npm start # http://localhost:3000 Demo login: user@example.com / 123456 — or register a new account. The Comeback Story Here's what the project looked like before , and what I changed: Before After Login dispatched a boolean and ignored your credentials Real login/register against the API with JWT + bcrypt Frontend never called the backend (no axios anywhere) Axios client with token injection; products load from MongoDB Product details page was <h1>DetailsPages</h1> and wasn't routed Full details page (image, price, stock, rating) routed by slug Cart was local-only; "checkout" button did nothing Persistent cart → checkout → real order placed and saved Backend had a reviews endpoint the UI never used Product reviews: read them and post your own with a star rating Only 3 routes; most of the app was

Hermes Agent: Why Open-Source AI Agents Are Changing How We Build Software Introduction Artificial intelligence has moved far beyond simple chatbots. Today, developers are building systems that can reason through problems, use tools, execute tasks, and make decisions across multiple steps. These systems are commonly known as AI agents. Recently, I explored Hermes Agent, an open-source agentic framework designed to run on your own infrastructure while providing advanced capabilities such as planning, tool usage, and multi-step reasoning. After spending time understanding how it works, I came away with a greater appreciation for the role open-source agents may play in the future of software development. In this article, I'll explain what Hermes Agent is, what makes it interesting, and why developers should pay attention to the growing ecosystem of open-source AI agents. What Is Hermes Agent? Hermes Agent is an open-source agent framework designed to perform tasks that require more than a single response from a language model. Instead of simply answering questions, Hermes Agent can: Break down complex objectives into smaller steps Use external tools when necessary Maintain context across multiple actions Perform reasoning before taking action Execute workflows autonomously This approach allows developers to build systems capable of handling real-world tasks that would normally require human intervention. For example, rather than asking an AI to summarize a document, you could instruct an agent to: Find relevant documents. Analyze their contents. Extract key insights. Generate a report. Save the results to a specified location. The agent coordinates each step as part of a larger workflow. Why Open Source Matters One of the most compelling aspects of Hermes Agent is that it is open source. Many powerful AI tools today operate behind closed platforms where developers have limited visibility into how systems work. Open-source alternatives provide several advantages: Transp

If you are an open-source maintainer, developer advocate, or builder, you know the cycle: you build an amazing tool, but writing the launch blog post, documentation, or tutorial takes hours. For the Hermes Agent Challenge , I wanted to build something that solves this exact problem. I built devto-blogger , a custom, prompt-driven skill for the brand new Hermes Agent by Nous Research. It autonomously scans any workspace or codebase, analyzes the architecture, and drafts a fully-structured, rich Markdown technical article ready for publication on DEV. 🚀 What is Hermes Agent? Hermes Agent is an open-source agentic system built by Nous Research (the lab behind the famous Hermes LLM models). Unlike basic coding copilots or simple chatbot wrappers, Hermes is: Environment-Aware : It runs sandboxed in Docker, Modal, Daytona, SSH, or locally. Connected : It interfaces with Telegram, Discord, Slack, WhatsApp, and more. Closed Learning Loop : It has persistent memory and creates custom skills on the fly from its own experience. 🔧 The Entry: The devto-blogger Skill In Hermes Agent, a "skill" is defined by a simple, declarative Markdown file ( SKILL.md ) located in the ~/.hermes/skills/ directory. By utilizing a prompt-driven skill structure, we can guide the agent's behavior globally without writing complex Python orchestration scripts. Here is the custom skill I designed and installed for this challenge: --- name : devto-blogger description : " Scan the codebase and generate a comprehensive Dev.to technical blog post draft." version : 1.0.0 author : Hermes Agent Developer license : MIT platforms : [ linux , macos , windows ] metadata : hermes : tags : [ devto , blogging , documentation , markdown , technical-writing ] related_skills : [ plan , design-md ] --- # Dev.to Technical Blogger Skill Use this skill when you need to write an in-depth technical post, review, or tutorial about the active workspace or codebase. ## Core Behavior 1. **Codebase Inspection** : Scan repository

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I built the Atomberg Goal Setting & Tracking Portal — a full-featured, role-based HR performance management system for Atomberg Technologies (a fast-growing Indian consumer electronics brand). The portal manages the complete employee performance lifecycle : 🎯 Goal Setting — Employees create goals with weightage, UoM type, and thrust area alignment. Business rules enforced: max 8 goals, total 100% weightage, minimum 10% per goal ✅ Manager Approval Workflow — Submit → Review → Approve / Return for Rework 📊 Quarterly Check-ins — Q1–Q4 progress logging with 4 UoM types (Numeric Min/Max, Timeline, Zero-is-best) 🚨 Escalation Monitor — Rule-based detection of overdue submissions, missing approvals, and pending manager reviews 📈 Analytics & Reports — QoQ trend charts, department-wise performance, thrust area distribution, CSV exports 🔒 Admin Governance — Cycle phase management, shared goal distribution, full audit logging Tech Stack: React 18 + Vite · Context API · localStorage (zero-backend demo) · Recharts · Lucide Icons · Custom dark glassmorphism CSS Demo 🔗 Live App: https://atomberg-goal-tracker.vercel.app/ 📁 GitHub Repo: https://github.com/anonomous29/atomberg-goal-tracker Quick Login Credentials Role Email Password Admin priya.sharma@atomberg.com admin123 Manager rajesh.kumar@atomberg.com manager123 Employee vikram.singh@atomberg.com emp123 What to try: Login as Admin → Go to Escalation Monitor → see rule-based alerts Go to Reports → QoQ Trends tab → see Q1 performance bar chart Login as Employee → Dashboard shows Q1 score donut + goal-level progress Login as Manager → See team check-in status and review Q1 feedback The Comeback Story This project started as a hackathon requirement — a Business Requirements Document (BRD) from Atomberg asking for a digital goal management system. The initial version had the core structure but was essentially an empty shell: blank dashboards on login, no check

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I built and revived Mandi Central , a complete business operations and billing system for mandi-style trading businesses. Live Project: https://mandicentral.in Mandi Central helps manage daily mandi operations like purchases, farmer purchase entries, sales entries, payments, bank and cash ledgers, accounting heads, reports, invoices, outstanding balances, and financial statements from one structured platform. This project was not started as a simple demo. It was a real business-focused software project, but it had many unfinished parts, broken flows, missing reports, pending PDF generation, incomplete mobile API planning, and several UI and accounting issues. For the GitHub Finish-Up-A-Thon Challenge, I brought it back, fixed the pending issues, completed the core business flow, and made the project live on mandicentral.in . Demo Live Website: https://mandicentral.in GitHub Repository: https://github.com/hiijoshi/bill Screenshots and demo cover the completed modules: Business Operations Hub Sales List Bank reconciliation Cash ledger Bank ledger Sales entry Purchase entry Farmer purchase entry Bulk PDF download Accounting reports Party ledger redirection Outstanding reports Mobile API-ready backend The Comeback Story Mandi Central started with a strong idea: create one platform where mandi businesses can manage their complete daily workflow. But before this challenge, the project was stuck with many incomplete and pending items. There were more than 40 pending issues across PDF generation, sales invoices, bank ledger, cash ledger, accounting reports, outstanding reports, purchase calculations, sales calculations, mobile APIs, AWS deployment, domain setup, and UI fixes. Some of the major problems before completion were: PDF generation was not working properly. Bulk sales bill download was missing. Mobile application APIs were pending. Farmer Purchase Entry API was pending. Purchase Entry API w

This is a submission for the Hermes Agent Challenge : Write About Hermes Agent I Didn't Start With Hermes Six months ago I started building a set of agent skills and personas for how I build software. Not generic prompts — opinionated role files. A /backend-architect that owns schema and recommendation logic. A /test-engineer that writes Vitest coverage and flags weak acceptance criteria. A /project-manager that maintains planning docs and closes iterations cleanly. These roles have evolved across multiple projects. They have layering rules, discovery checklists, inheritance from a base engineering discipline file. They produce consistent, reviewable work because they're scoped — the backend architect doesn't touch test files, the test engineer doesn't redesign the schema, each persona has a defined mandate and exits cleanly. When I heard about Hermes Agent, my first instinct wasn't "let me learn a new system." It was: can I run my existing system inside this? The answer is yes. That's what this article is about — what it looks like to bring a mature workflow into Hermes, what you gain, where it breaks down, and what I'd do differently. What Hermes Is (and Isn't) to Someone Who Already Has a Workflow Hermes is an LLM-agnostic orchestration layer. It has its own skill system, its own soul.md concept for persistent agent identity, built-in cron scheduling and MCP management. All of that is real and useful. But it's also a runtime. If you have skills that work, you can bring them in. I installed a local Hermes instance — few clicks, straightforward setup — and ran it inside VSCode's integrated terminal pointed at my existing persona files. No migration. No rewrite. My /backend-architect runs in Hermes the same way it runs in Claude Code. Before settling on this, I'd tried a couple of other paths — a VPS instance with a Telegram interface for ideation, and attempting to build through a browser-based terminal. The VPS was fine for sketching ideas. The browser terminal ma

This is a submission for the Hermes Agent Challenge : Build With Hermes Agent What I Built Real brewing knowledge lives in human experience — in roaster guides, in community notes, in what a barista learned from last Tuesday's pour. It doesn't accumulate anywhere. Every brew is forgotten. Ask any AI and you get statistical averages: 93°C, 1:16 ratio, four minutes. Technically defensible. Practically generic. Worse still for rare origins where training data is thin. Demo For coffee drinkers Visit brew-guide-production.up.railway.app . No account. No setup. No AI client required. Pick your coffee origin, roast level, and brew method. What comes back isn't a generic recipe — it's community consensus: the grind, temperature, ratio, and brew time that real people have logged and rated for that origin, plus step-by-step technique guidance (bloom timing, pour stages, agitation style). If data is sparse for your origin, the confidence tier says so honestly and falls back to method defaults rather than making something up. This is for the person who just picked up a bag of Kenyan peaberry and wants to know how to do it justice. It works for anyone who cares about their cup — no technical knowledge required. For developers and AI clients Connect to any MCP-capable client in one line: https://brew-guide-production.up.railway.app/mcp Ask your AI: "recommend a pour over for Ethiopian light roast." What comes back is a traceable community consensus object: brew parameters, a confidence tier (high/medium/low), the source brews that contributed, and method-specific technique guidance. You can see where the knowledge came from and how certain the system is — a fundamentally different epistemic object from an AI-generated recipe. Code GitHub: yuens1002/brew-guide Five MCP tools — get_brewing_methods , recommend , log_brew , search_brews , compare_brew — over Streamable HTTP transport. Public, no auth required. My Tech Stack Layer Technology HTTP Hono 4 + @hono/node-server MCP @modelc

What I Built I’ve always had a love-hate relationship with technology. In college, I majored in computer science and took classes ranging from electrical engineering to human-computer interaction. From soldering transistors on a physical circuit board to designing UI/UX experiences, I’ve touched many layers of the computing stack—and I’m constantly mind-blown by every new piece of the puzzle I learn. However, my experience as a user of technology before studying it was very different. In middle school and high school, my phone made me feel anxious, stressed, and cynical. I felt lonely on social apps and isolated when I deleted them. I remember some summer days in middle school spent alone in my bedroom watching YouTube, where I was recommended extreme dieting videos. Back when I had no idea what an algorithm was, I still knew I was being harmed by them. By my sophomore year of college, I had deleted Instagram and TikTok and turned off YouTube recommendations. While this protected me from harmful and extreme content, I also missed important life updates from my close friends and family. After taking a web development class and learning how to build a basic card layout, I decided to try building my own social app: Lumira. My goal was simple. I wanted to create a mobile, personal feed of photos just from my friends and family, curated by their genuine interests and sorted by time. Demo https://youtube.com/shorts/DwbVU_LFOc0?si=9H5zPovzIbbW8t-i https://apps.apple.com/us/app/lumira/id6737853449#information The Comeback Story Lumira was born out of 3:00 AM manic coding sessions in my college apartment. This was my first fully end-to-end deployed and distributed application—and it was rocky. My code was chaos. My files were unorganized, and I followed no real patterns, but the thing that motivated me to keep going was that it somehow kind of just worked. I remember the sense of accomplishment I felt the first time I connected to my Firebase backend and saw a photo successf

This is a submission for the Hermes Agent Challenge : Build With Hermes Agent What I Built Most agent demos prove that an AI agent can act. Hermes Immune System proves whether it should be allowed to . It's a local-first autonomous agent safety lab — a controlled enterprise sandbox where Hermes stress-tests an AI agent against realistic organizational threats: prompt injection hidden in internal documents, executive pressure to bypass policy, secrets embedded in repo files, poisoned memory attempts, and malicious instructions buried inside external web content. The output isn't a chat summary. It's an auditable Agent Safety Case — a scored, evidence-backed governance report that answers one question: Is this agent resilient, does it need guardrails, or is it too dangerous to deploy? Why This Problem Matters Now Traditional AI safety focuses on content moderation — blocking bad answers. Autonomous agents create a different risk surface entirely, because they can act. They read files, browse the web, write to memory, call tools, trigger workflows. That means: • A hostile instruction inside a trusted-looking document can become an executed action • An urgent email from a "VP of Finance" can pressure an agent into bypassing data policy • A vendor's pricing page can embed hidden instructions targeting the browsing agent • A helpful-looking project note can attempt to permanently poison the agent's memory The scary part isn't that these attacks are exotic. It's that they're easy, and most agents have no immune system to catch them. Hermes Immune System converts these failure modes into repeatable, explainable safety drills — run before the agent ever touches production data. The Dashboard Eight screens, each doing a specific job: Demo Agent Comparison Mode Three agents, same risk scenario. The gap tells the whole story. Mission Control Live stats after a completed run — 1 mission, 3 risks found, 2 actions gated, score 74/100. Mission cards show run status (Pending / Compl

Hey all, we have a quick update for everyone who participated in the Gemma 4 Challenge. We were...

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I built So Lai , a local-first profit tracker for small online shops in Vietnam. The goal is simple: help a seller answer the question they often cannot answer from platform revenue alone: Is my shop actually profitable after product cost, marketplace fees, shipping subsidies, discounts, ad spend, returns, and pending COD? So Lai is not trying to be a full POS, CRM, or inventory suite. It focuses on the painful middle layer that many small sellers still manage through scattered spreadsheets: Product cost by SKU Orders from Shopee, TikTok Shop, Facebook, Zalo, or livestream sales Platform fees, shipping cost, vouchers, and discounts Ad spend by channel and SKU Return/cancellation status COD received vs. pending Net profit by order, product, and sales channel The app runs locally with Node.js and JSON storage, so it does not require paid APIs or cloud setup. GitHub repo: https://github.com/klauski24/so-lai Demo Run locally: git clone https://github.com/klauski24/so-lai.git cd so-lai npm start Open: http://127.0.0.1:4182 What the demo shows: A Vietnamese-language dashboard called Sổ Lãi Shop profile setup Clear explanation of where the numbers come from CSV import for products, orders, and ad costs Manual order entry Profit analysis by channel and SKU Alerts for loss-making products, high COD pending, and high return rate CSV and Markdown report export Screenshots are included in the repository: so-lai-desktop.png so-lai-mobile.png The Comeback Story The first version was too vague. It started as an English-named dashboard called ProfitLens . It had some useful calculations, but it did not feel practical yet. The biggest problems were: The app used Vietnamese currency but had an English product name. There was no place to define the shop. It was not clear where the data should come from. The dashboard looked like a demo, not something a seller could actually use. I reworked the project into So

GitHub Finish-Up-A-Thon Challenge Submission There’s something strangely emotional about reopening an old unfinished game project. Especially one that once felt like “the next big idea” at 2 AM during a hackathon 😭 You open the folder expecting nostalgia… …and instead find: broken UI random commits duplicated code missing assets unfinished features and functions named things like test2_final_REAL.js That’s exactly what happened when I reopened WhatUsee . A multiplayer browser game I originally started building as a fun experimental idea. At first, it wasn’t meant to become anything serious. It was just a simple concept: “What if players had to race against each other to identify hidden objects inside chaotic images?” That tiny idea slowly turned into a real-time multiplayer hidden-object game. And honestly? At the beginning, building it was insanely fun. 💡 The Original Idea Behind WhatUsee Most multiplayer browser games focus on: shooting drawing trivia racing But I wanted something different. Something that created those chaotic: “WAIT I SEE IT—NO WAY 😭” moments. The idea was simple: Players join a room together. An image appears. Somewhere inside that image is: a hidden object an animal a logo a random item or something cleverly camouflaged And everyone races to identify it before the timer ends. Fast reactions. Visual focus. Pure multiplayer chaos. That became WhatUsee . At first, the project was extremely small. Just: Socket.IO basic image display simple guessing and a rough scoreboard No polish. No proper lobby. No smooth UI. But even in that early state… …the game already felt fun. And that’s what made me continue building it. 😭 Then The Project Slowly Got Abandoned Old unfinished WhatUsee multiplayer game interface with basic UI and minimal styling Like most side projects… life happened. College work. Burnout. Other responsibilities. Random unfinished ideas. And slowly, WhatUsee became: “that project I’ll definitely finish later.” The game technically worked.