Do you know the difference between radio buttons and checkboxes?

I recently ran into a few misunderstandings while using polls in Telegram with multiple selections enabled. The poll shows radio buttons even though users can select multiple options.

By default:

• Radio buttons signal single choice
• Checkboxes signal multiple choices

So when users see radio buttons, they think they can pick only one option. And that’s exactly leading to unexpected results if you create a multiple selection pool.

Users trust visual patterns more than instructions. When UI elements don’t match their expected behavior, misunderstandings are inevitable.

Clarity and consistency in UI are not optional — they directly affect how people think and act.

UI #Frontend #Telegram

You changed one line in your system prompt and broke three downstream features. No tests caught it because — let’s be honest — you don’t test your prompts.

Here are three dead-simple bash scripts I use to catch prompt regressions before they hit production.

Script 1: The Golden Output Test

This script sends a fixed input to your prompt and diffs the output against a known-good response.

#!/bin/bash
# test-golden.sh — Compare prompt output against golden file

PROMPT_FILE="$1"
INPUT_FILE="$2"
GOLDEN_FILE="$3"

ACTUAL=$(cat "$PROMPT_FILE" "$INPUT_FILE" | 
  curl -s https://api.openai.com/v1/chat/completions 
    -H "Authorization: Bearer $OPENAI_API_KEY" 
    -H "Content-Type: application/json" 
    -d @- <<EOF
{
  "model": "gpt-4o-mini",
  "messages": [
    {"role": "system", "content": "$(cat $PROMPT_FILE)"},
    {"role": "user", "content": "$(cat $INPUT_FILE)"}
  ],
  "temperature": 0
}
EOF
  | jq -r '.choices[0].message.content')

echo "$ACTUAL" > /tmp/prompt-test-actual.txt

if diff -q "$GOLDEN_FILE" /tmp/prompt-test-actual.txt > /dev/null 2>&1; then
  echo "✅ PASS: Output matches golden file"
else
  echo "❌ FAIL: Output diverged"
  diff --color "$GOLDEN_FILE" /tmp/prompt-test-actual.txt
  exit 1
fi

Usage:

./test-golden.sh prompts/summarize.txt fixtures/input-1.txt fixtures/expected-1.txt

When to use: After any prompt edit. Set temperature: 0 for deterministic output. Update the golden file intentionally when you want the output to change.

Script 2: The Keyword Gate

Sometimes you don’t need exact match — you just need the output to contain (or NOT contain) specific terms.

#!/bin/bash
# test-keywords.sh — Assert required/forbidden keywords in output

PROMPT_FILE="$1"
INPUT_FILE="$2"
REQUIRED="$3"   # comma-separated: "function,return,async"
FORBIDDEN="$4"  # comma-separated: "TODO,FIXME,undefined"

ACTUAL=$(curl -s https://api.openai.com/v1/chat/completions 
  -H "Authorization: Bearer $OPENAI_API_KEY" 
  -H "Content-Type: application/json" 
  -d "{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "system", "content": $(jq -Rs . < $PROMPT_FILE)},
      {"role": "user", "content": $(jq -Rs . < $INPUT_FILE)}
    ],
    "temperature": 0
  }" | jq -r '.choices[0].message.content')

PASS=true

IFS=',' read -ra REQ <<< "$REQUIRED"
for keyword in "${REQ[@]}"; do
  if ! echo "$ACTUAL" | grep -qi "$keyword"; then
    echo "❌ Missing required keyword: $keyword"
    PASS=false
  fi
done

IFS=',' read -ra FORB <<< "$FORBIDDEN"
for keyword in "${FORB[@]}"; do
  if echo "$ACTUAL" | grep -qi "$keyword"; then
    echo "❌ Found forbidden keyword: $keyword"
    PASS=false
  fi
done

if $PASS; then
  echo "✅ PASS: All keyword checks passed"
else
  echo "--- Actual output ---"
  echo "$ACTUAL"
  exit 1
fi

Usage:

./test-keywords.sh prompts/code-review.txt fixtures/pr-diff.txt 
  "security,error handling" "looks good,LGTM"

Script 3: The Format Validator

For structured output (JSON, YAML, specific sections), validate the shape — not the content.

#!/bin/bash
# test-format.sh — Validate output structure

PROMPT_FILE="$1"
INPUT_FILE="$2"
FORMAT="$3"  # "json" | "has-headers" | "max-lines:N"

ACTUAL=$(curl -s https://api.openai.com/v1/chat/completions 
  -H "Authorization: Bearer $OPENAI_API_KEY" 
  -H "Content-Type: application/json" 
  -d "{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "system", "content": $(jq -Rs . < $PROMPT_FILE)},
      {"role": "user", "content": $(jq -Rs . < $INPUT_FILE)}
    ],
    "temperature": 0
  }" | jq -r '.choices[0].message.content')

case "$FORMAT" in
  json)
    if echo "$ACTUAL" | jq . > /dev/null 2>&1; then
      echo "✅ PASS: Valid JSON"
    else
      echo "❌ FAIL: Invalid JSON"
      echo "$ACTUAL"
      exit 1
    fi
    ;;
  has-headers)
    if echo "$ACTUAL" | grep -q "^#"; then
      echo "✅ PASS: Contains markdown headers"
    else
      echo "❌ FAIL: No markdown headers found"
      exit 1
    fi
    ;;
  max-lines:*)
    MAX="${FORMAT#max-lines:}"
    LINES=$(echo "$ACTUAL" | wc -l)
    if [ "$LINES" -le "$MAX" ]; then
      echo "✅ PASS: $LINES lines (max: $MAX)"
    else
      echo "❌ FAIL: $LINES lines exceeds max $MAX"
      exit 1
    fi
    ;;
esac

Putting It Together

I run all three in a Makefile:

test-prompts:
    ./test-golden.sh prompts/summarize.txt fixtures/doc-1.txt fixtures/expected-summary-1.txt
    ./test-keywords.sh prompts/review.txt fixtures/pr-1.txt "security,performance" "LGTM"
    ./test-format.sh prompts/extract.txt fixtures/email-1.txt json

Hook it into CI:

# .github/workflows/prompt-tests.yml
on:
  push:
    paths: ['prompts/**']
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test-prompts
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Now every prompt change gets tested automatically. Total setup time: 20 minutes. Regressions caught since I started: seven.

Your prompts are code. Test them like it.

We’re going to make a claim that might sound controversial:

Uptime monitoring and website monitoring are not the same thing. Most people use the terms interchangeably. They shouldn’t.

Uptime monitoring answers: “Did the server respond?”
Website monitoring answers: “Does the site work?”

Those sound similar. They’re not. And the gap between them is where most silent failures live.

What uptime monitoring actually does

Let’s be specific about what a typical uptime monitoring tool checks. There’s no ambiguity here — this is the standard model that tools like UptimeRobot, Pingdom, Better Stack, and most others follow:

1. Send an HTTP request to your URL
2. Receive a response
3. Check the status code
4. If it’s 200 OK → mark as healthy
5. If it’s 5xx or timeout → mark as down
6. Report uptime percentage

That’s it. That’s the check.

It tells you whether your server is alive and responding to requests. It does that well. And for a long time, that was enough — because if the server was up, the site worked.

That’s no longer true.

What uptime monitoring does NOT check

Here’s a non-exhaustive list of things a standard uptime check will miss:

Asset integrity. Your HTML loads, but the JavaScript bundle it references returns 404 because you deployed and the CDN still serves old HTML pointing to deleted files. The page is a blank white screen. Status code on the document: 200.

MIME types. Your server returns a JS file with Content-Type: text/html. The browser downloads it, reads the header, silently refuses to execute it. Your SPA never boots. Status: 200.

Redirect chains. Your site redirects /page → /page/ → /page → /page/. The browser gives up after 20 hops. Your uptime tool followed the first redirect, got a 200, and moved on.

Content correctness. Someone changed your homepage in the CMS at 2am. Or your CDN started serving content from the wrong origin after a migration. The page loads — it’s just the wrong page. Status: 200.

Third-party dependencies. Stripe’s JS fails to load. Your checkout renders as an empty div. Your auth provider is down. Users can’t log in. Your page loaded fine — the broken resource is on someone else’s domain.

Regional divergence. Your site works from US-East. In Frankfurt, the CDN edge serves stale cached assets from three deploys ago. Single-region uptime checks never see this.

Every single one of these returns 200 OK. Every single one passes a standard uptime check. Every single one is broken for users.

What website monitoring checks instead

Website monitoring starts where uptime monitoring stops. Instead of asking “did the server respond?”, it asks “did the response constitute a working page?”

That means:

Treating the HTML document as a manifest, not a destination. The document is step one. Website monitoring follows up — do the JS and CSS bundles it references actually load? Do they return the right MIME types? Do they return valid status codes?

Following redirect chains to completion. Not just the first hop. The full chain. Does it resolve? Does it loop? Does it end somewhere unexpected?

Fingerprinting content over time. If the response body changes without a deployment, you want to know. Content fingerprinting with SHA-256 hashes catches silent CMS edits, CDN origin drift, and cache poisoning.

Checking from multiple regions. CDN failures are regional by nature. A site can be perfect in one location and broken in another. Website monitoring runs the full check suite from multiple geographic locations independently.

Classifying root cause. Not just “something is wrong” but “why.” Is this a deployment artifact? A CDN cache issue? A DNS drift? An application error? Root cause classification turns an alert into actionable information.

A practical comparison

Here’s the same scenario through both lenses:

Scenario: You deploy a Nuxt 3 app to Vercel. The build succeeds. But a CDN edge node in Europe still serves the previous HTML, which references app.7fb2e.js. That file was deleted in the new build.

Same site. Same moment. Completely different picture.

They’re complementary, not competing

We want to be clear about something: we’re not saying uptime monitoring is useless. It’s not. You absolutely need to know when your server is down. A 503 or a timeout is a real outage and you need to know about it immediately.

The problem is treating uptime monitoring as sufficient. It’s one layer. It catches one type of failure. The failures it misses — the “200 OK but broken” failures — are increasingly the ones that actually hurt users.

The monitoring stack for a modern web application should have both:

Uptime monitoring → Is the server alive? Is it responding? Is the infrastructure running?

Website monitoring → Does the site work? Are assets loading? Is the content correct? Does it work everywhere?

If you only have the first, you have a blind spot. And it’s the kind of blind spot where your dashboard says 99.9% uptime while your users are staring at blank pages.

This is why we built Sitewatch

Sitewatch is website monitoring. Not uptime monitoring. The distinction matters to us because it’s the entire reason the product exists.

We check asset integrity, MIME types, redirect chains, content fingerprints, and multi-region consistency. When something breaks, we classify root cause — infrastructure, application, or content delivery — and provide fix guidance tailored to your tech stack.

Every check runs a 2-of-3 retry confirmation model so you don’t get woken up at 3am for a transient CDN hiccup. Duplicate alerts are deduplicated with SHA-256 fingerprinting and a 30-minute cooldown.

Free tier for 1 site. No credit card. Takes 30 seconds: getsitewatch.com

Uptime monitoring tells you the server is alive. Website monitoring tells you the site works. They’re not the same question — and the answer to one doesn’t imply the answer to the other.

On March 31, 2026, two malicious versions of axios were published to npm: [email protected] and [email protected]. Both were live for roughly three hours before npm pulled them down. During that window, anyone who ran npm install axios could have had a Remote Access Trojan (RAT) dropped silently on their machine or CI runner, with no errors and no warnings.

This post breaks down what happened, how the attack worked, and the exact commands to check if you were affected.

What happened

The attacker compromised the npm account of the primary axios maintainer. Using stolen credentials, they published two new releases across both the 1.x and 0.x branches within 39 minutes of each other. The account’s registered email was quietly changed to an attacker-controlled ProtonMail address before the releases went out.

Here is what makes this attack stand out: there is zero malicious code inside axios itself. Both releases simply added one new runtime dependency to package.json: a package called [email protected], which had never appeared in any legitimate axios version.

When you ran npm install, npm resolved and installed that dependency automatically, which triggered its postinstall script and silently executed the dropper.

The malicious dependency: plain-crypto-js

[email protected] was staged 18 hours before the axios releases, by a separate attacker-controlled account. It masquerades as a clone of the legitimate crypto-js library, with an identical description and the real author’s name in the manifest. Visually, it looks harmless. The only difference from the real package is a single extra field in package.json:

"scripts": {
  "test": "grunt",
  "postinstall": "node setup.js"
}

That setup.js is a cross-platform RAT dropper.

What setup.js does

The dropper detects your operating system and then:

• macOS: writes an AppleScript to /tmp, executes it via nohup osascript, downloads a binary to /Library/Caches/com.apple.act.mond (named to blend in with Apple system processes), makes it executable and launches it
• Linux: fetches a Python script from the C2 server to /tmp/ld.py and runs it in the background
• Windows: copies PowerShell to %PROGRAMDATA%wt.exe (disguised as Windows Terminal), then uses a VBScript to silently fetch and execute a PowerShell payload

All of this runs in under two seconds from the moment npm install starts. The npm install itself exits with code 0 and shows no errors.

The anti-forensics layer

After launching the payload, the dropper:

1. Deletes setup.js from node_modules/plain-crypto-js/
2. Deletes the malicious package.json
3. Renames a pre-staged clean stub (package.md) to package.json, which reports version 4.2.0 with no scripts

After the swap, running npm audit reveals nothing. Running npm list plain-crypto-js shows version 4.2.0. The only reliable on-disk evidence is the existence of the node_modules/plain-crypto-js/ directory, since this package was never a dependency of any real axios release.

A note on the publish metadata

Every legitimate axios 1.x release is published via GitHub Actions with npm’s OIDC Trusted Publisher mechanism, meaning the publish is cryptographically tied to a verified workflow. [email protected] breaks that pattern entirely. There is no corresponding tag or commit in the axios GitHub repository. It was published manually using a stolen npm access token.

Am I affected?

The malicious versions were live between approximately 00:21 UTC and 03:15 UTC on March 31, 2026. If you did not run npm install (or a fresh npm ci) during that window, you were likely not hit.

Run through these steps to verify.

Step 1: Check for the malicious axios versions

npm list axios 2>/dev/null | grep -E "1.14.1|0.30.4"
grep -A1 '"axios"' package-lock.json | grep -E "1.14.1|0.30.4"

No output means you are probably fine. Any output means those versions were installed.

Step 2: Check for plain-crypto-js in node_modules

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

If the directory exists, the dropper ran. Do not rely on the version number inside it.

Step 3: Check for RAT artifacts on the system

macOS

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "COMPROMISED"

Linux

ls -la /tmp/ld.py 2>/dev/null && echo "COMPROMISED"

Windows (cmd.exe)

dir "%PROGRAMDATA%wt.exe" 2>nul && echo COMPROMISED

Step 4: Check for C2 activity in logs

grep -r "sfrclak.com" ~/.npm/_logs/ 2>/dev/null
grep "sfrclak" ~/.bash_history ~/.zsh_history 2>/dev/null

Step 5: Check your CI/CD pipelines

Review any npm install runs in GitHub Actions or other CI systems between 00:20 UTC and 03:15 UTC on March 31. Any pipeline that ran with those axios versions should be treated as compromised, and all secrets injected in that workflow should be rotated immediately.

If you got multiple projects running

for dir in ~/projects/*/; do
  if [ -f "$dir/package.json" ]; then
    result=""
    if ls "$dir/node_modules/plain-crypto-js" 2>/dev/null | grep -q .; then
      result="DROPPER FOUND"
    fi
    axios_hit=$(grep -A1 '"axios"' "$dir/package-lock.json" 2>/dev/null | grep -E "1.14.1|0.30.4")
    if [ -n "$axios_hit" ]; then
      result="$result | MALICIOUS AXIOS VERSION"
    fi
    if [ -n "$result" ]; then
      echo "⚠️  $dir → $result"
    else
      echo "✅  $dir"
    fi
  fi
done

Remediation

1. Downgrade to a safe version

# 1.x users
npm install [email protected]

# 0.x users
npm install [email protected]

2. Pin the version in your package.json

{
  "overrides":   { "axios": "1.14.0" },
  "resolutions": { "axios": "1.14.0" }
}

3. Remove plain-crypto-js and reinstall

rm -rf node_modules/plain-crypto-js
npm install --ignore-scripts

4. Block the C2 domain (macOS / Linux)

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
sudo iptables -A OUTPUT -d 142.11.206.73 -j DROP

5. Add –ignore-scripts to your CI installs going forward

npm ci --ignore-scripts

This prevents any postinstall hook from running during automated builds, which would have stopped this attack entirely.

If you found a RAT artifact

Do not try to clean the machine in place. Rebuild from a known-good state and rotate everything that was accessible during the compromised install: npm tokens, AWS access keys, SSH private keys, cloud credentials, CI/CD secrets, and any .env values present at install time.

Indicators of Compromise

Takeaways

This attack did not require any vulnerability in axios itself. It exploited the trust developers place in a well-known package name and a familiar maintainer account. The entire weapon was a single extra line in package.json.

A few habits that would have reduced exposure here:

• Run npm ci --ignore-scripts in CI pipelines as a standing policy
• Use npm’s Trusted Publisher provenance statements to verify releases were published from the expected CI workflow
• Watch for new dependencies appearing in transitive installs that were not there before
• Pin your lockfile and review package-lock.json diffs in pull requests

The full technical breakdown, including the decoded dropper, process tree, and file swap events captured at runtime, is in the StepSecurity report.

Stay safe.