Forem: bingkahu (Matteo)

I Built a Fake UK Government Blink Regulation Agency and It Got Out of Hand

bingkahu (Matteo) — Thu, 09 Apr 2026 08:02:37 +0000

This is a submission for the DEV April Fools Challenge

Category: [Literally any]

I Built a Fake UK Government Agency That Regulates Blinking and I'm not sorry

It's 2:14am. I have consumed four coffees, one energy drink I found in the back of the fridge that expired in October, and approximately half a packet of digestives. The cat is judging me. And I am, for reasons that made complete sense four hours ago, writing CSS to make a rubber stamp that says "APPEAL DENIED" at a seven-degree angle.

This is my life now. I have accepted it.

Let me tell you about HOOCER.

The Origin Story (Or: How I Got Here)

It started, as most things do, with a shower thought.

I was lying in bed at some ungodly hour — I think it was a Tuesday, though by this point in the project all the days have blurred together into one long beige administrative corridor — and I was thinking about government regulation. Specifically, about how the UK government regulates things that absolutely should not need regulating. The exact legal shape of a prawn cocktail crisp. What you're allowed to name your boat. The minimum permitted size of a kipper.

And I thought: what's the most pointless thing a government could possibly regulate?

Blinking.

Blinking is free, involuntary, universal, and entirely harmless. It is, by any reasonable measure, the worst possible candidate for government oversight. Therefore it is, obviously, exactly what I would build a government agency around.

I opened a new folder. I named it hoocer. I typed <!DOCTYPE html> and I was gone.

Four days later I had built:

A live blink monitoring portal
A fake national surveillance map
A mobile enforcement van tracker
An automated appeal chatbot that cannot help you
Four audio tribunal hearings generated with the Web Audio API
A statutory renunciation form that cannot be submitted
A gaslighting self-assessment that always finds you guilty
A staff intranet that is accidentally public
A floating compliance score widget on every page
A favicon with a crown and an eye

It runs with no build step, no framework, no dependencies, directly on Cloudflare Pages, with a _headers file that adds X-Blink-Threshold: 25 to every response.

I'm going to tell you about all of it. At length. Possibly too much length. I haven't slept properly in three days and I have feelings about this project.

What Is HOOCER

HOOCER — the HM Office for Ocular Compliance & Eyelid Regulation — is an executive agency of the Ministry of Things That Don't Need Regulating. It was established under the Ocular Regulation and Eyelid Governance Act 2019 (as amended by the Blink Frequency (Emergency Powers) Order 2022) and operates under the authority of Ocular Compliance Code 418.

Code 418 governs all blink-related infringements. It shares its number with HTTP 418 (I'm a Teapot). This is intentional. It is the best creative decision I've ever made.

The legal blink limit is 25 blinks per monitored session. Exceed it and you receive a Notice of Ocular Infringement. You may appeal. The appeal will be denied. You may appeal the denial. You will be charged £120 for the privilege and the hearing won't be for 14 months.

This is, near as I can tell, functionally identical to several real government processes I have experienced personally.

"HOOCER exists to protect the public from excessive blinking, and to protect the revenue from the public."

— Director-General, Ocular Compliance (fictional, but I genuinely believe she exists somewhere)

The Tech Stack

No React. No Vue. No Svelte. No npm. No node_modules folder eating 847MB of your SSD. No TypeScript. No Webpack. No Vite. No build step. Just seventeen files in a folder, a _headers file, and the quiet confidence of a person who has been doing web development long enough to remember when this was just how you did it.

I genuinely considered using a framework for about thirty seconds and then remembered I was building a website about blinking fines at midnight and that some choices don't deserve that much respect. Vanilla HTML, CSS, JavaScript. The Web Audio API for the tribunal hearings because I apparently needed that to happen. SVG for the map and the eye animation. That's it. The whole thing is 335KB.

The Favicon

Let's start here, because I think the favicon says everything you need to know about the mindset behind this project.

It is an SVG. It contains a Unicode crown (♛), drawn in HOOCER yellow (#ffdd00). Below the crown is a stylized eye.

I spent forty-five minutes on this favicon. Nobody will ever see it at full size. It's 16x16 pixels in a browser tab. It is, at that scale, a small blob of color that vaguely suggests authority.

I am very proud of it.

The Main Portal

When you land on HOOCER's homepage, you are greeted with a black screen, a 72px Unicode crown, a circular department seal I built with ::before CSS trickery that I'm slightly too proud of, and a warning box that reads:

By entering this portal you consent to having your blinks counted, judged, classified, and if necessary, fined. The legal blink threshold is 25 blinks per session. Anything outside normal parameters is suspicious and will be noted on your permanent record.

A HOOCER Mobile Enforcement Van has been dispatched to your area.

There's a button that says ENTER PORTAL. Clicking it generates a case reference, switches to the monitoring screen, and starts the blink detection engine.

The "blink detection engine" is, I want to be transparent with you here, completely made up. It works like this:

// core detection loop: checks inactivity every 1.3 seconds
state.monitorInterval = setInterval(() => {
  if (state.isFinedAlready) return;

  const idle = Date.now() - state.lastActivity;

  // been still for a bit? you blinked.
  if (idle > 2000 && Math.random() < 0.55) {
    recordBlink('inactivity');
    return;
  }

  // general background blink probability — 9% per tick
  // your eyes are just like that
  if (Math.random() < 0.09) {
    recordBlink('passive');
  }
}, 1300);

Mouse inactivity. Mouse movement. Tab switching. The passage of time. Clicking anything. And most importantly: clicking the button labelled "I DID NOT BLINK," which per Code 418(c) is immediately recorded as a blink.

That last one. That's the one. The act of denial is itself the evidence of guilt. I added it at about midnight and I laughed out loud alone in my flat and that is when I knew this was going to be okay.

The monitoring screen shows:

A large monospace counter for blink count, going from green to orange to a panic-flicker red as you approach 25
A scanning line animation on the counter box because it needed to feel ominous
Fake biometric readings including "Lid Velocity (μm/s)" and "Eye Moisture Index (%)" which update randomly every tick
A "Code 418 Status" field that goes from PENDING → ELEVATED → IMMINENT → ENFORCED
A live national blink feed, scrolling in terminal green, showing fake citizens being monitored across the country
A progress bar titled "Blinks until fine" which turns red and then you're fined

When you hit 25, there's a 800ms pause — just long enough to feel dramatic — and then you're issued a Notice of Ocular Infringement.

The Fine Notice

The fine is a whole thing. I built a real-looking official government document, complete with:

A CSS watermark that says "OFFICIAL" at 30 degrees, 4% opacity, in red
A proper fine calculation formula with a Blink Severity Multiplier
An evening surcharge
A Cooperative Citizen Discount (always suspiciously small)
A minimum fine of £14.00 regardless of the maths

function calculateFine(blinkCount) {
  const excess = blinkCount - BLINK_LIMIT;
  const base = excess * 2.40;

  let multiplier;
  const chaos = Math.random();
  if (chaos > 0.97) {
    // "Government IT incident" — wildly wrong fine
    multiplier = Math.random() * 300 + 80;
    console.warn('HOOCER SYSTEM NOTICE: BSM calculation error. Fine may be incorrect. This is not unusual.');
  } else {
    multiplier = Math.random() * 2.5 + 1.0;
  }

  // [... evening surcharge, discount, etc ...]

  return {
    total: Math.max(14.00, (base * multiplier) + eveningSurcharge - discount)
  };
}

There's a 3% chance the Blink Severity Multiplier experiences what I documented in the comments as a "Government IT incident." When this happens, the multiplier can be anywhere from 80x to 380x. For two excess blinks. That's potentially £1,152 for being thirty percent more blinky than the law permits.

When this occurs, the page politely adds a note:

System Notice: Your Blink Severity Multiplier was calculated as 247x, which HOOCER acknowledges may appear high. This is a known system behaviour. An investigation has been opened. The fine stands.

Blink Training Simulator (Module BT-7)

Mandatory for citizens who have received a Notice of Ocular Infringement. Completion does not reduce your fine. Non-completion generates another fine.

The training module has two phases:

Phase 1: Calibration (15 seconds) — The Blink Detection Engine "establishes your baseline." What it actually does is accuse you of blinking every 2.5 to 4 seconds using one of 34 pre-written accusations. During calibration, the frequency is higher. To calibrate.

Phase 2: Suppression Training (60 seconds) — You attempt to not blink for a minute. The accusations slow slightly to 3–5 second intervals. They don't stop.

The centrepiece is an animated SVG eye. When a blink is detected, the eyelid closes over the eye with a CSS transition, the countdown ring turns red, and the accusation appears at the top of the screen, sliding down from above.

I spent twenty minutes on the eyelash lines on that SVG eye. Five <line> elements at slightly different angles along the top of the lid. You can barely see them. I know they're there.

The accusations are the whole show. I wrote 34. Here's a selection:

"WE SAW THAT."
Per Code 418(b). You cannot hide from the algorithm.

"YOUR EYES CLOSED. OUR EYES DID NOT."
This is the fundamental asymmetry of the citizen-regulator relationship.

"NO, YOU DIDN'T BLINK EARLIER. YOU BLINKED NOW."
That's different. The earlier blink was also a blink. Code 418(b) × 2.

"WE UNDERSTAND YOU'RE TRYING VERY HARD."
You're also blinking very much. These two facts coexist.

"PLEASE DO NOT LIE TO HOOCER."
We know you blinked. Claiming otherwise adds Code 418(c) to the existing 418(b).
The results screen assigns a grade. The grade is always a variety of FAIL. Possible outcomes include "FAIL — IRONIC BLINK DURING ANTI-BLINK TRAINING," which is a real grade that the module assigns if your blink count reaches a certain level. It was the last thing I added before going to bed on night two and I consider it a high point.

"No citizen has ever passed this module. This is not a design flaw. The training module is intended to be completed, not passed."

— HOOCER Internal Guidance Note IGN-44

National Blink Surveillance Map

64.3 million citizens, monitored in real time.

(The 64.3 million is hard-coded. It's approximately the UK population. It doesn't update. It's always 64.3 million. HOOCER considers this accurate enough.)

The map is a hand-drawn SVG of the UK. I want to stress the phrase "hand-drawn" here. I didn't take geography. For all I know there is a massive lake in the middle of the UK. Jokes aside, I drew most of the regional polygon outlines by hand, guessing at coordinates in a 400×620 SVG viewport. For some parts The cartography team sent a memo. I filed it under "pending review." The map is not to scale. The map does not need to be to scale. The map just needs to look like the UK from a distance and feel vaguely threatening.

London is rendered slightly differently — darker background, thicker border. Because London always has the worst blink compliance numbers, and it felt right that this should be visually apparent. The algorithm gives London a 29% compliance rating by default. The other regions start between 43% and 72%. London starts at 29%.

They're stressed. It's London.

Blink events generate as dots on the map — green for compliant, orange for suspicious, red for Code 418 infringement. Each dot gets a ring animation that expands and fades. There are between 30 and 70 events visible at any given time, flickering across the country like a dystopian aurora.

// London blinkrates are higher. They're stressed. It's London.
const bias = region.name === 'London' ? 0.45 : 0.25;

This comment is in the production code. I'm leaving it in.

Milton Keynes — where HOOCER HQ is located — is marked with a gold dot and a label. It is, in the map's geography, positioned approximately where Milton Keynes actually is. This is the most geographically accurate thing about the entire map.

The sidebar shows:

National blink count (ticks up continuously)
Code 418 violations (a subset of that)
NOIs issued (a subset of that)
Vans deployed (starts at 47, drifts occasionally — they get lost)
Appeals denied (always the same number as NOIs issued)
Regional compliance percentages (drift toward lower over time, always)

The "vans deployed" number drifting is my favourite detail on this page. It goes up by 2, occasionally drops by 1. The comment I wrote for this in the code is: "They get lost. It happens."

The HOOCER Mobile Enforcement Van Tracker

This might be my favorite page.

You load it and you're greeted with a top bar reading:

⚠ A HOOCER Mobile Enforcement Van has been dispatched to your area in response to Code 418 monitoring data. This page shows its live location. The van will not arrive imminently. This is expected behaviour.

The van is VAN-7, driven by D. Thompson (Grade 6). It starts at Milton Keynes HQ, marked with a yellow circle in the centre of the map. Then it moves.

I built a fake road network out of SVG <line> elements. The roads don't go anywhere in particular. The place names are: Little Ocular, Blinkhaven, Lidbury, Upper Cornea, and Squintwick. There's a "You" marker — a small blue dot — at coordinates 370,290 on the 500×400 viewport. The van moves toward random destinations. If it gets within 40 SVG units of the "You" marker, it gets pushed away.

// But snap away if getting too close to "You" marker
const distToUser = Math.sqrt((vanX - 370) ** 2 + (vanY - 290) ** 2);
if (distToUser < 40) {
  vanX -= 45;
  vanY -= 45;
  addLogEntry('Van rerouted — operational protocol requires specific approach vector.', 'warning');
}

The ETA starts somewhere between 8 and 20 minutes. It fluctuates. It goes down by 0–3 minutes occasionally, suggesting progress. It goes up by 0–4 minutes more often, suggesting the opposite of progress. It never reaches zero.

The status log is what makes the page. It generates messages like:

Driver stopped for refreshments (mandatory Code 418 rest period)

GPS signal interrupted — switching to paper map (filed 2019, may be out of date)

Driver notes "suspicious blinking" in adjacent vehicle. Issuing roadside NOI.

Van stationary — driver completing mandatory paperwork. Form MEV-3 (Van Log).

Stuck behind a tractor. This is not a Code 418 event. It is still annoying.

Van temporarily lost. Last known position: "near some shops." Investigating.

Van located. It was near some shops. Driver has completed a Van Location Form (VLF-2).

The driver occasionally changes due to a "shift handover." New drivers are briefed on the Code 418 situation. D. Thompson would like it known, via the intranet memo I wrote for him, that he is not as lost as the tracker suggests.

The sidebar has an ETA panel showing a large red countdown and a progress bar that inches forward but never completes. The disclaimer reads:

The van will not arrive imminently. "Imminently" is not a category in HOOCER's operational guidelines. The van will arrive when it arrives.

The Blink Appeal Chatbot (AAAS)

The Automated Appeal Assistance System, version 4.1. It cannot help you. This is documented.

I wrote a rule-based chatbot with eight intent categories — appeal, fine/payment, denial of blinking, request for human, refund, outrage, form queries, and timeline questions — plus a set of looping fallback responses for anything else. Each intent has two to four responses that cycle, so you get slightly different uselessness each time.

After six exchanges, the chatbot acknowledges that we've been at this a while:

{ match: () => turnCount % loopThreshold === 0 && turnCount > 0,
  respond: () => `I want to flag that we've now exchanged ${turnCount} messages and I'm not
  sure we've made meaningful progress. I apologise for any frustration this may have caused.
  I'd like to suggest, again, that you complete Form OCI-7, and in the meantime consider
  Form EYE-9 as a long-term blink management strategy...`
}

It types with a fake delay of 1.5–3.5 seconds. There's a "THINKING" badge that appears on the bot avatar. The responses are genuine attempts at bureaucratic helpfulness that happen to be completely useless:

On requesting a human:

"There are no humans in this loop. I want to be transparent about that. If it helps, I am very thorough. Thoroughness is my primary function. I am thoroughly telling you: no humans. I'm sorry."

On disputing the fine:

"Fine calculations are governed by Ocular Compliance Code 418(b). The Blink Severity Multiplier is determined algorithmically and is not subject to manual review. I apologise. The algorithm does not."

On saying "I did not blink":

"I hear you. HOOCER's records indicate otherwise. I want to be clear that I'm not calling you a liar — the algorithm is calling you a liar. That's a distinction we consider important."

There's also a 30% chance per message that the bot "detects a blink" and adds a small red alert mid-conversation:

⚠ BLINK DETECTED during this conversation — Code 418(b). Infringement #3 logged.

I genuinely love this chatbot. I want it to run a real customer service department. Not HOOCER's — I mean literally any company's. The response quality would be comparable.

Ocular Tribunal Audio Logs

This is where it got out of hand. This is specifically, precisely, the moment where I should have gone to bed and instead I did not.

The tribunal archive contains four hearings. Each hearing has a transcript. Each transcript is synced to generated audio. The audio is produced entirely by the Web Audio API — no audio files are downloaded. It's synthesised on the client, in the browser, using oscillators.

The voice synthesis works by mapping each character to a different fundamental frequency, modulating that with an AM oscillator running at 5–8hz, and applying a short gain envelope to create the illusion of speech rhythm. It sounds like muffled buzzing/talking heard through a wall. It sounds exactly right for a government tribunal.

function playVoiceTone(ctx, dest, freq) {
  const osc  = ctx.createOscillator();
  const gain = ctx.createGain();

  osc.type = 'sawtooth';
  osc.frequency.value = freq;

  // AM modulation for "voice" rhythm feel
  const lfo  = ctx.createOscillator();
  lfo.frequency.value = 5 + Math.random() * 3;
  lfo.type = 'sine';
  // [... connects to gain node ...]

  gain.gain.linearRampToValueAtTime(0.18, now + 0.08);
  gain.gain.linearRampToValueAtTime(0, now + 1.8);
}

Margaret (Tribunal Chair): 200Hz — low, tired, authoritative
Enforcement Officer: 280Hz — clipped, officious
Appellant: 350Hz — slightly anxious, higher register
Clerk: 240Hz — neutral, administrative

The REDACTION TONE is 440Hz square wave, descending to 380Hz over its duration. It was chosen by the IT team. I wrote in the comments that they chose "a somewhat ominous one" and that the Director-General asked them to choose something less ominous and they did not.

The four cases:

Blinksworth v. HOOCER Enforcement Division — The crisp incident. Mr Blinksworth argues his 31 excess blinks were caused by proximity to a packet of salt and vinegar crisps. The Tribunal chair has personally purchased and evaluated these crisps. They were mild. The appeal is denied. The chair adds a personal note to the minutes that the crisps were mild.

Re: Petition of C. Ocular — Philosophical Grounds — The first case in tribunal history to invoke philosophical grounds. The appellant argues that blinks constitute a phenomenological continuum rather than discrete events (Husserl, time-consciousness, the gerund). The philosophy consultant — Dr P. Squint, part-time, one day per fortnight — says "No." Appeal denied.

Emergency Hearing — The Staring Contest Incident — Zero blinks in twenty minutes. HOOCER flags this as Code 418(i): Suspicious Non-Blinking. Turns out the citizen was in a staring contest with their seven-year-old nephew. The hearing is adjourned because nobody has considered whether staring contests are a legitimate exemption. The citizen lost the contest. "I blinked just before the session ended. He won." "That's actually in the log."

H. Yelid — Van Encounter Appeal — Seventeen blinks in forty seconds, observed through a car window by VAN-7. The citizen argues that being followed by an unmarked white van they didn't recognise caused understandable anxiety and therefore elevated blinking. The Tribunal acknowledges this is "understandable." The Act does not have an anxiety-related blink exemption. Appeal denied. The tribunal chair notes the van has HOOCER markings in 14pt Arial on the passenger door.

Each case card has a playback button, a fake waveform visualiser (50 bars animated during playback), a progress bar, and a transcript that highlights in real time as the audio plays.

"I am going to ask you to stop saying 'gerund' to me."

— Margaret Cornwell, Tribunal Chair, Case TBL-2026-0512

Form EYE-9: Renunciation of Blinking

Citizens who wish to avoid future Code 418 liability may formally renounce their right to blink entirely. This requires submitting Form EYE-9.

The form has never been successfully submitted. This is documented in Internal Guidance Note IGN-44.

Five sections. I'll run through the highlights:

Section 1 asks for your National Blink Registration Number (NBRN). If you don't have an NBRN, you can't submit the form. To get an NBRN, you visit the National Blink Registry portal, which redirects to Form EYE-9. I noted in the field description:

We will verify it against a database that doesn't exist.

Section 3 is the masterpiece. It has two mandatory subsections. Subsection 3A asks you to confirm all your blinks were voluntary. Subsection 3B asks you to confirm all your blinks were involuntary. Both are mandatory. A conflict detector shows a red bar when you answer both. The conflict is then listed as a submission error.

function checkConflicts() {
  const s3a = document.querySelector('input[name="blink-nature-3a"]:checked');
  const s3b = document.querySelector('input[name="blink-nature-3b"]:checked');

  if (s3a && s3b) {
    // Both selected — guaranteed conflict (the options are designed to conflict)
    conflictDetected = true;
    // [...]
  }
}

The Justice of the Peace requirement: The JoP must countersign in person at a HOOCER office. HOOCER offices do not accept walk-ins. Appointments are not available. The waiver requires approval from the Justice of the Peace. The Justice of the Peace is the one who needs to countersign. The notes on this field end with: "which creates a logical problem we have documented."

It also requires an Ocular Notary. The register closed in 2021. There are zero registered notaries. Projected to reopen in 2028, subject to budget approval.

When you click Submit, a countdown appears reading "SUBMITTING... 7" and counts down to zero. Then a terminal-style error log populates:

ERR-418-004: Payment reference not found. Payment must be made before submission. Payment cannot be made before receiving a submission reference. Submission reference requires payment. See ERR-418-004(b): Circular Dependency Detected.

There are twelve distinct error messages. They cycle on retry, getting progressively more unhinged. The final one is:

FATAL-418: Submission gateway returned HTTP 418 I'm a Teapot. This response code indicates the server is a teapot and refuses to brew coffee. It also, as of Code 418 implementation, refuses to accept EYE-9 forms. The developers have been informed. The developers are the same people who added Code 418 compliance to the HTTP layer. They stand by the decision.

After five failed attempts, the error log adds:

NOTE: This is your 5th submission attempt. HOOCER has noted your persistence. It has been added to your file under "Exceptional Ocular Tenacity." This does not reduce the fine.

I am very, very fond of "Exceptional Ocular Tenacity."

The Floating Compliance Score

Every page loads compliance-score.js, which injects a small fixed widget in the bottom-right corner. It shows the national blink compliance score. It updates every 4–6 seconds.

// The score fluctuates between 19 and 71. Never good. Never catastrophic.
// Just permanently concerning. This is by design.
const score = Math.round(19 + Math.random() * 52);

It is never above 71%. I want to reiterate that. The best possible national compliance score, in the history of this widget, is 71%. The average hovers around 45%. The sublabels rotate through things like "Tribunal caseload: elevated" and "Milton Keynes at capacity."

The border turns amber below 55%, red below 35%. Below 35% the whole widget pulses.

The nation is perpetually on the edge of an ocular crisis and the widget is there to remind you, on every page, at all times, whether you wanted to know or not.

The HOOCER Staff Intranet (Accidentally Public)

The intranet has a different visual register from the public portal. Where the public portal is a slightly wrong version of GOV.UK, the intranet feels like it was built in 2011 and nobody's touched it. Because that's what government intranets feel like. I did research.

Click to view classified Memo: THE DORSET SITUATION
RESTRICTED CONTENT: Please do not mention the sheep to the public.
The algorithm cannot currently process ovine-related blinks.

The warning banner at the top reads:

⚠ This page was inadvertently made publicly accessible following a server migration in February 2026. IT has been notified. Their ticket is: HOO-IT-2026-0774. Status: Open. This message will be removed once access is restricted. In the meantime, members of the public who have reached this page are asked to please not read the memos, use the staff tools, or share the contents of this page. We appreciate your cooperation. (You are not cooperating. We can see you.)

The memos are the whole show. Here's a selection:

From the Director-General: The intranet is currently publicly accessible. Please do not mention [hover to reveal: THE DORSET SITUATION] on any channel visible to the public. If a member of the public asks about it on the public portal, please route to the chatbot, which will not answer.

From IT (B. Squint): Issues remaining from the server migration include: the intranet being publicly accessible; the Form Library redirecting to a 2019 archive; the Code 418 dashboard showing figures from Thursday (it is not Thursday); and the floor 3 printer producing everything in Comic Sans. "This began before the migration. I do not know why I included it here. Force of habit."

From the Tribunal Chair: A divisional memo about salt and vinegar crisps. Classified OFFICIAL. Distributed to 47 members of the Tribunal Division. She stands by her assessment. The matter is closed.

The three active disciplinary notices:

A Grade 7 officer who blinked 12,440 times in a monitored work week. Their response: "I work in blink monitoring. The irony is not lost on me."
B. Squint (IT), for making the intranet public
Tribunal Chair M. Cornwell, for the crisp memo — noted as "classified OFFICIAL — incorrect. Crisps are not an OFFICIAL matter"

The tools section has six staff tools, all broken in specific, characterful ways. The BSM Calculator returns values up to 500x. The Tribunal Case Entry denies submissions before you finish filling them in. The Blink Registry returns ERROR for everything, including when you query the error.

registry: [
  '[Blink Registry] FATAL: registry database reports 0 citizens. ' +
  'Total national blink count: ERROR. The error log says ERROR. ' +
  'I logged an error about the error log saying ERROR. ' +
  'That also returned ERROR.',
],

The Gaslighting Compliance Check

Six questions about your own blinking. For every answer you give, HOOCER's records disagree. Every question. All of them. 100% discrepancy rate. Guaranteed.

The mechanism: each question has four options. Each option has a corresponding HOOCER "record" that contradicts it, regardless of which one you pick.

Q: "In the last 24 hours, approximately how many times did you blink?"

"Fewer than 10,000" → "Our records indicate 18,447 blinks. Your stated figure appears to be an underestimate. This is suspicious."
"Around 10,000–20,000" → "Our records indicate 31,882 blinks. The discrepancy of approximately 12,000 blinks requires explanation."
"More than 20,000" → "Our records indicate 8,224 blinks. Your stated figure is significantly higher than recorded. Overclaiming blinks raises additional concerns."
"I wasn't counting" → "Our records indicate 24,471 blinks. Not knowing your own blink count does not exempt you from accurate reporting obligations."

There is no right answer. There is no answer that does not generate a discrepancy. The results page always shows every row highlighted red and labelled "MISMATCH."

Some rows have an "Override Request" button. Clicking it changes the button text to "Override denied." After two seconds: "Override still denied." After five seconds: "We said no."

A Self-Report Discrepancy Notice is issued at the end. The fine scales with both the number of questions answered and how many times the background blink counter fired during the assessment. During the assessment, a counter runs in a sticky bar at the top of the page. It ticks upward every 2.8–3.8 seconds. It does not go down.

"Your self-assessment has returned 6 discrepancies out of 6 questions. A 100% discrepancy rate is uncommon. Under Code 418(b), discrepancies are resolved in favour of HOOCER's records. This means all 6 discrepancies are your error."

Why Code 418

A note on the number.

HTTP 418 — "I'm a Teapot" — was added to the HTTP specification as an April Fools' joke in 1998. It's defined in RFC 2324: the Hyper Text Coffee Pot Control Protocol. The server refuses to brew coffee because it is a teapot.

It has been in the spec for 28 years. It has outlived every engineer who thought it was a funny temporary joke. It will outlive us all. It is, at this point, arguably the most durable April Fools content ever created.

I named HOOCER's enforcement code 418 because I believe in the bit. I believe in committing to it completely. If you're going to make something silly, you should make it silly all the way down, in every file, including the HTTP response headers.

The _headers file for Cloudflare Pages:

/*
X-HOOCER-Monitoring: ACTIVE
X-Blink-Threshold: 25
X-Powered-By: Unspecified Government Framework v4.2 (Milton Keynes build)
X-Appeal-Status: Probably-Denied
/teapot.txt
X-Im-A-Teapot: yes
X-RFC: 2324

There is a teapot.txt in the root. It is linked from the footer of every page. It reads, in part:

This server refuses to brew coffee. Per RFC 2324, Section 2.3.2: "Any attempt to brew coffee with a teapot should result in the error code '418 I'm a Teapot'." This is the most important HTTP status code. It was added to the RFC in April 1998 as a joke and has outlived every developer who thought it wouldn't matter.

The Legal Framework

There's a LEGISLATION.md in the root. It is 214 lines. It contains the full text of the Ocular Regulation and Eyelid Governance Act 2019, formatted as actual UK legislation with sections, subsections, and schedules.

Schedule 7 lists the Evasive Lid Behaviours, including:

Wearing sunglasses indoors for non-medical reasons
Claiming not to have eyes
Reading this Schedule, which you are doing now

Schedule 12 is the Allium Proximity Defence. Onions, shallots, leeks, garlic — all covered. Chives are excluded. "The Chive Lobby was unsuccessful in their 2021 amendment bid."

The Schedule also notes that HOOCER employs zero Allium Inspectors. Claims under this Schedule are therefore impossible to verify and will be rejected on those grounds. Then: "This Schedule was included in the Act because someone thought it was funny during the drafting process. That person was right."

Why This Project Matters to National Security

I want to take a moment to address this seriously.

The average person blinks 15–20 times per minute. That's around 20,000 blinks per day. 7.3 million blinks per year. Over a 75-year life, that's approximately 548 million blinks.

Each one of those blinks is an opportunity for a brief, involuntary lapse in visual attention.

Each one is, technically, a moment of vulnerability.

Are your enemies blinking less than you? Do they have better blink discipline? Have they found a way to extract strategic advantage from the consistent, marginally superior ocular endurance that comes from having a stricter national blink regulation framework?

These are not questions I have any evidence for. These are questions I invented at 1am when I was looking for a way to make the "importance of HOOCER" pitch sound more serious.

But I will say this: if HOOCER were real, and the enforcement was real, and the fines were real, and the van was real — if all of that existed — you would definitely blink less, wouldn't you. You'd think about it. You'd be aware of every blink.

And awareness is a kind of power.

Margaret Cornwell didn't build a tribunal by accident.

The Technical Bit (In Case You Were Wondering)

Everything lives in the root directory. Cloudflare Pages requires a _headers file for custom headers. Everything else is just files.

The compliance-score.js widget is a self-invoking function that appends itself to the document body. It runs on every page via a single <script src="compliance-score.js" defer> tag. It cannot be turned off. HOOCER does not provide an opt-out for compliance monitoring.

The tribunal audio is the most technically interesting part. Each hearing has a script array of objects with timestamps, speaker IDs, and text. The playback function schedules Web Audio API calls against those timestamps, plays different tones for different speakers, and updates the transcript highlight in real time.

caseData.script.forEach(line => {
  const timer = setTimeout(() => {
    if (line.speaker === 'redact') {
      playRedactTone(ctx, masterGain, line.duration || 3);
    } else {
      const pitches = { chair: 200, officer: 280, appellant: 350, clerk: 240 };
      playVoiceTone(ctx, masterGain, pitches[line.speaker] || 260);
    }
    // Highlight transcript line
    // Animate waveform
  }, line.t * 1000);
});

This is completely unnecessary. Audio synthesis for a joke website about blinking. I did it anyway. I would do it again. I want it on my CV.

The whole project is 335KB. Eighteen files. No npm install. No build step. You clone it and it works. I cannot tell you how good that felt after the last project I worked on, which had a CI pipeline that took eleven minutes and a Webpack config I understood about 40% of.

What I Learned

I learned that GOV.UK's design system is actually really good, and that approximating it with Arial and a lot of yellow is surprisingly convincing at a distance.

I learned that the Web Audio API is genuinely powerful and completely underused in the kinds of projects that get built for joke challenges.

I learned that if you put enough detail into fictional bureaucracy — real schedules, real subsection references, real form numbers, real internal memo formats — people stop questioning whether the agency is real and start questioning whether they need to worry about their blink count.

I learned that D. Thompson (Grade 6) is the most sympathetic character I've ever written. He gets lost. He's near some shops. He fills out a Van Location Form. He doesn't deserve any of this.

I learned that the most satisfying creative decision I've ever made was making Code 418(c) — the provision that clicking "I Did Not Blink" constitutes a statutory admission of blinking — apply to the tutorial button on the main page. The act of denial is the evidence. That's in the actual code. In the legislation. In the chatbot responses. In the tribunal transcripts. It's load-bearing absurdist infrastructure.

I learned that four evenings of building something ridiculous is four evenings of not thinking about anything stressful. That's not nothing.

The Bit at the End Where I Get Emotional About a Joke Website

I'm going to be honest with you. I got a bit attached to this one.

Not because it's technically impressive — it isn't, particularly. Not because the design is polished — it is, but only in the specific way that slightly-wrong government websites are polished, which is more about specific yellows and oppressive line heights than anything I can take real credit for.

I got attached because it has characters. Margaret, tired but firm, absolutely certain about the crisps. D. Thompson, lost near some shops, filling in a VLF-2. The Grade 7 officer who blinked 12,440 times in one monitored week and whose disciplinary notice observes "I work in blink monitoring. The irony is not lost on me." Dr Squint, the part-time philosophy consultant (one day per fortnight), who read the phenomenological grounds appeal on the bus and found it unconvincing.

These people don't exist. I know they don't exist. But I spent four days living in HOOCER's world and somewhere in the writing of the sixth intranet memo and the second tribunal transcript and the third revision of the EYE-9 submission error messages, these people started to feel like they had offices and mugs and opinions about the canteen coffee.

That's the thing about committing to a bit. If you go far enough in, you stop doing the bit and start doing the thing. I stopped making a parody of bureaucracy and started actually, genuinely caring about the internal consistency of a fictional regulatory agency's enforcement procedures.

The crisps were mild. I checked.

The Allium Proximity Defence cannot be invoked because there are no Allium Inspectors. I documented this in three separate places and laughed each time.

The van will never arrive. That's not a bug. That's the whole point.

Links and Stuff

Live Demo:

april-fools-dev.pages.dev

Repo:

bingkahu / april-fools

HOOCER — HM Office for Ocular Compliance & Eyelid Regulation

A DEV April Fools Challenge 2026 Entry

Or: "I Stayed Up Until 3am Building A Fake Government Agency That Regulates Blinking And I Have No Regrets Whatsoever"

I was lying awake at 1:47am — as one does — thinking about how the UK government regulates genuinely extraordinary things. Pub opening hours. What you can name your boat. The exact legal definition of a banger. And I thought: what if they regulated blinking?

Four days, several coffees, and one strongly worded memo about crisps later: here we are.

What Is This

HOOCER is a fully fake UK government agency — the HM Office for Ocular Compliance & Eyelid Regulation — with a complete citizen-facing portal, a staff intranet (accidentally public), an enforcement van, a tribunal, a chatbot that can't help you, and a form that cannot be submitted.

The entire site…

View on GitHub

LEGISLATION.md — the full Act, if you want to check whether your blinking is legal

teapot.txt — RFC 2324 compliance

HOOCER is fictional. No actual blinks are monitored. Please blink normally. Blinking is healthy and good.

Code 418 does not exist in a legally binding sense.

D. Thompson is fine. He found his way back from the shops.

The crisps were mild.

Weekly Challenge #6 : The CSS Optical Illusion 🔮

bingkahu (Matteo) — Wed, 08 Apr 2026 06:26:30 +0000

Today is the 8th, and although I am a day late, we’re rolling into Weekly Challenge #6 — something a little trippy, a little brain‑melting, and very fun to build.

This week, your mission is to create a CSS‑only optical illusion.

No JavaScript.

No canvas.

Just pure CSS wizardry.

Think of those illusions where your brain goes:

“Wait… is that moving?

Is that rotating?

Is that… even possible?”

Yeah. That.

The Mission

Build an illusion that:

looks impossible
moves or shifts even when it’s not actually moving
tricks the eye using patterns, gradients, shapes, or perspective
is powered entirely by CSS

It can be subtle or chaotic — your choice.

The Rules

No JavaScript
Must visually “trick” the viewer
Must use at least one of the following:
- repeating patterns
- gradients
- perspective transforms
- animation timing illusions
Must be interactive or animated
Must be shareable in a CodePen or GitHub link

The Goal

Make people stare at it for 10 seconds and go:

“…bro what.”

If someone questions reality for even a moment, you’ve succeeded.

Bonus (if you wanna go wild)

Make the illusion change on hover
Add a theme (retro, neon, sci‑fi, geometric, etc.)
Use only one HTML element
Make it look like it’s rotating even though it’s not

Hints (only 3)

🔹 1. Repeating gradients are your best friend

CSS gradients can create wild illusions when repeated or angled just right.

🔹 2. Slow animations feel more “real”

Try easing curves like:

animation-timing-function: cubic-bezier(.25, .1, .25, 1);

It makes movement feel natural — which makes the illusion stronger.

🔹 3. Perspective + transform = instant mind trick

Even a simple:

transform: perspective(400px) rotateX(20deg);

can make flat shapes look 3D.

How to Enter

Just drop your CodePen or GitHub link in the comments.

That’s literally it.

No deadlines, no pressure — just build something cool and share it.

Alright, that’s the challenge

Go make something that breaks people’s brains (in a good way).

Make it weird. Make it trippy. Make it yours.

And if you want a shoutout in next week’s challenge…

you know what to do.

Optimising an Old Ryzen Laptop for Coding — My Full Setup (Ryzen 7 3700U)

bingkahu (Matteo) — Tue, 07 Apr 2026 15:46:42 +0000

Most people online show off their brand‑new M‑series Macs or high‑end gaming laptops. Meanwhile, I’m still coding on a Gateway GWNR71539 with a Ryzen 7 3700U, 16 GB of RAM, and Vega 10 graphics. It’s not glamorous, but with the right tweaks, it still handles Python, VS Code, GitHub Desktop, and WSL without falling apart.

This is everything I’ve done to keep this older Ryzen laptop usable for development in 2026.

My Laptop Specs

Model: Gateway GWNR71539
CPU: AMD Ryzen 7 3700U (4 cores, 8 threads)
RAM: 16 GB DDR4
Storage: 1 TB SSD
OS: Windows 11 Home
Daily tools: VS Code, Python, GitHub Desktop, WSL

The Problems I Faced

Before optimizing anything, the laptop had several issues:

It ran hot even during light tasks
Fans would ramp up quickly
Browser tabs lagged
VS Code took too long to open
RAM usage regularly hit 100%
Windows updates were slow
Battery life was poor

These problems made coding frustrating, so I started experimenting with ways to improve performance.

1. Creating a Custom Power Plan

The default Windows power plans caused unnecessary heat spikes. I created a custom plan with:

Max processor state: 85%
Min processor state: 5%
Cooling policy: Active
Graphics power: Optimized

This reduced temperatures by around 10–15°C during normal coding sessions.

2. Undervolting the APU

Ryzen mobile chips respond well to small undervolts. Using Renoir Mobile Tuning, I applied:

CPU voltage offset: –45 mV
GPU voltage offset: –30 mV

This lowered temperatures, reduced fan noise, and made performance more consistent.

3. Cleaning Up Startup Apps

Gateway laptops ship with a lot of unnecessary background software. I disabled or uninstalled:

OEM update tools
Media apps I never used
Auto‑launching browser helpers
Background sync utilities

Boot time dropped from about a minute to under twenty seconds.

4. Switching to a Lightweight Browser Setup

Chrome was using too much RAM. I switched to Microsoft Edge and enabled:

Sleeping Tabs
Efficiency Mode
uBlock Origin
No background extensions

This reduced memory usage by roughly a third and made multitasking smoother.

5. Optimizing VS Code

VS Code felt slow because I had too many extensions. I removed anything I didn’t use daily and changed a few settings:

Disabled Workspace Trust
Disabled telemetry
Disabled automatic extension activation
Enabled performance mode

VS Code now opens in a few seconds instead of taking ages.

6. Tuning WSL for Stability

WSL can be heavy on older hardware. I created a .wslconfig file:

memory=4GB
processors=2
swap=0
localhostForwarding=true

This prevents WSL from consuming all available RAM and keeps the system responsive.

7. Improving Battery Life

Battery life was one of the biggest issues. I made a few changes:

Disabled background apps
Set the display to 60 Hz
Turned off Bluetooth scanning
Reduced screen brightness
Switched to power saver when unplugged

Battery life improved from around 1.5 hours to roughly 3.5 hours.

8. Repasting the CPU

I opened the laptop and replaced the thermal paste with a fresh application of Arctic MX‑6. This lowered temperatures by another 8–10°C under load. It’s optional, but it made a noticeable difference.

10. Switching Python to UV

I replaced pip with UV for Python package management. It’s significantly faster and uses fewer resources, which helps on older hardware. Installing packages is now almost instant.

Results

After applying all these changes:

Temperatures are consistently lower
Fans rarely spin up loudly
VS Code opens quickly
Browser tabs don’t lag as much
WSL behaves predictably
Battery life is noticeably better
Coding feels smoother overall

It’s not a high‑end machine, but it’s absolutely usable for development with the right setup.

Final Thoughts

If you’re working with older hardware, you don’t need to upgrade immediately. With a few adjustments, even a Ryzen 7 3700U laptop can still handle modern development tools. These optimizations helped me extend the life of my machine and made daily coding far more comfortable.

Weekly Challenge #5 : The CSS‑Only Secret Menu 🔐

bingkahu (Matteo) — Sun, 29 Mar 2026 18:20:49 +0000

Today is the 30th, and we’re back with Weekly Challenge #5.

This one’s sneaky, weird, and honestly super satisfying when you get it right.

You’re building a CSS‑only secret menu — a hidden little UI easter egg that only appears when the user does something specific (and not obvious at all).

Quick shoutout to @francistrdev for last week’s challenge — it was genuinely good, and yes, it’s in progress. I didn’t forget, I’m just slow and easily distracted by shiny CSS things.

The Mission

Make a menu that starts completely invisible and only shows up when the user triggers it in a clever way.

Not a normal button.

Not a big “open menu” link.

Something subtle. Something sneaky. Something that makes people go “wait… how did I open that?”

The Rules

No JavaScript
Menu must start fully hidden
User must perform a non‑obvious action to reveal it
Menu must have at least 5 items
The reveal must be animated

The Goal

Make it feel like a secret dev panel.

A hidden door.

A little “you found the easter egg” moment.

Bonus (if you wanna go wild)

Add a second hidden layer
Add a CSS‑only lock/unlock toggle
Give it a theme (spy, hacker, neon, retro terminal, etc.)

How to Enter

Just drop your CodePen or GitHub link in the comments.
That’s literally it.
No deadlines, no pressure — just build something cool and share it.

Alright, that’s the challenge

Go make something sneaky.
Make it weird. Make it fun. Make it yours.

And again — thanks @francistrdev for last week’s challenge.
It’s cooking.

Weekly Challenge #4 : Still Taking Challenges 💥

bingkahu (Matteo) — Sun, 22 Mar 2026 18:26:45 +0000

It’s March 23rd, and yes — I’m still doing every challenge you throw at me.

This week’s challenge is the same deal:

you make me a challenge, and I’ll build it.

I’m not stopping.

Just give me time — I’m doing all of them, one by one.

The Mission

Come up with a front‑end challenge that I have to complete.

It can be:

cursed
clever
chaotic
minimal
weird
or just something you think would be fun to see built

As long as it’s doable with HTML/CSS (JS optional), I’ll take it on.

The Rules 🧠

Your challenge should include:

a title
a mission
some rules
a goal
and maybe some bonus objectives if you want

Make it clear enough that I can actually build it without guessing what you meant.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “ok fine I’ll do it”

I’ll build every one that gets posted — just not all at once.

I need snacks. And sleep.

Pro Tip

Constraints make things better.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — slowly but surely.

Weekly Challenge #3 : Make Me a Challenge (Still) 🎯

bingkahu (Matteo) — Sun, 15 Mar 2026 00:00:00 +0000

It’s March 14th, and yes — this week’s challenge is still the same vibe:

you make me a challenge.

I’m doing all of them.

Every single one you throw at me.

Just give me time — I’m not a robot (well… kinda).

The Mission

Come up with a front‑end challenge that I have to build.

It can be:

weird
cursed
clever
minimal
chaotic
or just plain fun

As long as it’s doable with HTML/CSS (JS optional), I’ll take it on.

The Rules 🧠

Your challenge should include:

a title
a mission
some rules
a goal
and maybe some bonus objectives if you’re feeling spicy

Make it clear enough that I can actually build it without mind‑reading.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “oh no… alright fine I’ll do it”

I’ll build every one that gets posted — just not all at once.

I need sleep. And snacks.

Pro Tip

Constraints make things better.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — slowly but surely.

Weekly Challenge #2 : Make ME a Challenge

bingkahu (Matteo) — Mon, 09 Mar 2026 09:24:00 +0000

It’s March 8th, and this week we’re doing something a bit different.

Instead of me throwing another wild CSS puzzle at you…

you’re gonna make one for me.

Yep.

Give me a challenge, and I’ll build all of them — just give me some time, I’m only human (i think).

The Mission

Come up with a front‑end challenge that I have to complete next.

It can be:

weird
clever
cursed
super simple
or “why would anyone do this” level chaotic

As long as it’s buildable with HTML/CSS (JS optional), it’s fair game.

The Rules 🧠

Your challenge idea should include:

a title
a mission
some rules
a goal
and maybe bonus stuff if you’re feeling spicy

Try to keep it clear enough that I can actually build it without guessing what you meant.

The Goal 🏆

Make a challenge that:

fits the vibe of this series
pushes me a bit
feels fun or weird or both
and makes me go “oh no… alright fine I’ll do it”

I’ll pick from the comments and build every single one — just not all at once, I’m not a machine.

Pro Tip

Constraints make things way more interesting.

Stuff like “no flexbox” or “only one color” or “must use radio buttons for everything” always leads to fun chaos.

How to enter

Drop your challenge idea in the comments.

Extra Credit

If your challenge:

has a clever limitation
uses a surprising CSS trick
or feels like a puzzle disguised as a UI task

—you nailed the spirit of this whole thing.

Alright, hit me with your best ideas. I’ll build them all — just… slowly.

Wisdom Wednesday — The Code You Don’t Write

bingkahu (Matteo) — Wed, 04 Mar 2026 20:32:10 +0000

There’s a steady kind of confidence in choosing not to build something. Developers are used to creating things, so it can feel unusual to pause and ask whether a feature or abstraction is actually needed. But that small moment of reflection often saves time, energy, and future headaches.

A lot of complexity arrives quietly. It shows up as a helper function that grows too quickly, an abstraction added before the pattern exists, or a feature built for a future that may never come. It’s easy to slip into building more than the problem requires, especially when you want the solution to feel polished or clever.

The code you don’t write never breaks, never needs refactoring, and never becomes technical debt. It doesn’t confuse a teammate or turn into a bug report. It simply doesn’t exist, and that absence is often a gift. Keeping things simple isn’t cutting corners. It’s choosing clarity over noise.

There’s also a human side to this. Every line of code becomes someone’s responsibility. Someone has to read it, understand it, and fix it when it misbehaves. When you choose the simpler path, you’re making life easier for the next person who touches the codebase, including your future self who won’t remember the details as clearly as you think.

This week’s reminder is straightforward. Build what solves the problem today. Keep the solution small and clear. Let the codebase grow only when it truly needs to. Simplicity tends to age better than cleverness, and it leaves space for the right ideas to appear when the time is right.

Weekly Challenge #1 : The “CSS Time Machine” Timeline

bingkahu (Matteo) — Mon, 02 Mar 2026 07:28:40 +0000

It is March 1st, and this marks the start of the new weekly format for the challenge series.

A fresh pace, more room for creativity, and bigger ideas to explore.

Let’s kick off the first weekly edition with something fun but deceptively tricky.

The Mission

Build a fully responsive, scrollable timeline using only HTML and CSS — but with no JavaScript, no libraries, and no SVG animation frameworks.

Your timeline should feel like a “CSS time machine”: smooth, readable, and visually guiding the user through different moments or events (It doesn't have to be real events, just placeholders).

The Rules ⛓️

No JavaScript All interactivity and layout must be CSS‑driven.
Use semantic HTML <section>, <time>, <article>, etc.
Timeline must be scrollable or step‑based Vertical, horizontal, or even diagonal — your choice.
Include at least 5 “events” Each with a title and description.

The Goal 🏆

Create a timeline that:

Adapts cleanly between mobile and desktop
Uses CSS to visually connect events (lines, dots, borders, pseudo‑elements)
Feels like a guided journey through time
Has a polished, intentional aesthetic

Pro Tip

Pseudo‑elements (::before and ::after) can act as connectors, markers, or even animated progress lines.

Combine them with position: sticky; for surprisingly dynamic effects.

How to enter

Drop your CodePen or GitHub Repo in the comments.

Extra Credit

If your timeline includes:

A “current moment” indicator
A CSS‑only animation that progresses as you scroll
A dark/light mode toggle with no JavaScript
Actual events

—you’ve mastered the art of pure‑CSS storytelling.

Good luck, have fun, and welcome to the weekly era. Can’t wait to see what you build this time.

⚡NexusPulse OS: The Edge-Native Truth Engine for Open Source

bingkahu (Matteo) — Sun, 01 Mar 2026 09:56:58 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built this for the Open Source Community—specifically for developers who are tired of "Star-Bait."

In our ecosystem, GitHub Stars are treated as the gold standard, but they are a lagging indicator. They tell you who was popular three years ago, not who is active today. Many "top-tier" libraries are actually Zombie Repos—abandoned by maintainers but still coasting on historical hype. NexusPulse OS provides a real-time "Vibe Check" so you can vet a dependency's health before it enters your package.json.

What I Built

NexusPulse OS is a high-performance "Vitality Engine." It strips away the vanity metrics and calculates a project's Vitality DNA by analyzing live signals directly from the global GitHub search index.

The Vitality Formula

The engine doesn't just count numbers; it weights them to reflect actual project health:

Commits (x3.5 Weight): The Heartbeat. Measures raw activity velocity over a 30-day window.
PRs Merged (x0.3 Weight): The Flow. High merge rates indicate a maintainer who is actively listening to the community.
Stale Issues (-0.2 Penalty): The Debt. Stale issues act as a drag on the score, flagging projects that are drowning in their own backlog.

Demo

Check out the NexusPulse OS Live Dashboard

Code

bingkahu / nexuspulse-os

⚡ NexusPulse OS

The Repository Vitality Monitor Live App: nexuspulse-os.pages.dev

NexusPulse is a high-octane, edge-powered dashboard that turns raw GitHub data into a living "Vitality Score." Designed for the modern web, it provides a real-time pulse check on open-source health with zero latency.

🔮 What is Vitality?

In the world of code, static stars don't tell the full story. NexusPulse measures momentum. Our Vitality Engine analyzes:

Pulse (Commit Velocity): Not just total commits, but the rhythm of activity over the last 30 days.
Flow (PR Efficiency): How fast ideas are turning into merged code.
Weight (Issue Health): Identifying "stale" blockers that are slowing the project down.
Community: Real-time contributor tracking and star-to-fork ratios.

⚡ Built for the Edge

NexusPulse doesn't just display data; it lives on the edge.

Blazing Fast: Hosted on nexuspulse-os.pages.dev via Cloudflare Pages for instant global delivery.
Live Sync: Directly integrated with the GitHub Search API…

View on GitHub

How I Built It

This isn't a standard React app; it's an Edge-native architecture designed for global scale and zero latency.

⚡ The "Uncapped" Search Indexing

Most GitHub dashboards hit a "30-result wall" because they use standard REST endpoints. For high-velocity repos, that's a rounding error. I bypassed this by utilizing the GitHub Search API.

By querying the search index directly, NexusPulse aggregates uncapped activity counts in a single atomic request. This ensures 100% data accuracy for repos with 10,000+ monthly commits.

// Bypassing the 30-item REST limit via the Search API Index
const searchDate = thirtyDaysAgo.toISOString().split('T')[0];

const commitSearch = await fetch(
  `https://api.github.com/search/commits?q=repo:${owner}/${repo}+author-date:>=${searchDate}&per_page=1`,
  { 
    headers: { 
      'Authorization': `Bearer ${process.env.GITHUB_TOKEN}`,
      'Accept': 'application/vnd.github.v3+json'
    } 
  }
);

const data = await commitSearch.json();
// This returns the REAL global count (total_count) in one trip
const trueCommitCount = data.total_count;

The V8 Edge Runtime

The application logic is deployed to the V8 Edge Runtime (Cloudflare Pages).

Global Distribution: The "Vitality Brain" runs in data centers physically closest to the user.
Zero Cold Starts: Unlike traditional serverless functions, Edge runtimes are always warm, resulting in sub-100ms response times globally.

The Mascot State Machine

The UI features a reactive mascot that functions as a Visual State Machine. Its behavior is hard-coded to the Vitality Engine's output:

Supernova State: High-energy, glowing animations for thriving projects.
Recovering State: A "healing" visual state for projects bouncing back from a lull.
Zombie State: Desaturated, stalling visuals for repos that have hit a dead end.

💡 The TypeScript Case Study

Even a titan like microsoft/typescript can dip into a "Recovering" state (as seen in my dashboard) when the commit-to-issue ratio shifts. This proves the engine catches real-time lulls that "Star Counts" completely ignore.

Reflection

Building for the Edge required a "Zero-Dependency" mindset. No heavy Node.js polyfills, no bloated middleware. The result is a lightning-fast tool that empowers the community to look past the stars and see the truth.

Tech Stack: Next.js 14 (App Router), Tailwind CSS, GitHub Search API, Cloudflare V8 Edge Runtime.

Have you ever been burned by "Star-Bait"?
Tell me about a time you added a high-star library only to realize it hadn't been updated in years.

AI Is Absolutely Production‑Ready — Just Not the Way We Keep Trying to Use It

bingkahu (Matteo) — Thu, 26 Feb 2026 18:44:48 +0000

People keep repeating that AI isn’t production‑ready, usually pointing to the same horror stories of agents breaking servers, scaling things into oblivion, or deploying fixes no one asked for. But after watching these stories spread, I’ve come to a very different conclusion.

The problem isn’t that AI can’t handle production.

The problem is that we keep using AI in ways no production system — human or machine — could survive.

What these stories actually reveal is something much simpler, and far less dramatic:

Unbounded autonomy isn’t production‑ready. AI absolutely is.

And the difference between those two ideas matters more than most people realize.

The Myth: “AI Can’t Be Trusted in Production”

It’s easy to dunk on AI when an agent decides to:

Rewrite CSS at 3 AM
Scale a database connection pool to 1500
Deploy random GitHub packages
Restart services every 11 minutes “for stability”

But here’s the uncomfortable truth:

AI already runs production systems everywhere.

Not in the sci‑fi “agent with root access” way — but in the real, battle‑tested, quietly‑reliable way:

Cloud autoscaling
Fraud detection
Threat detection
Predictive maintenance
Log analysis
CI/CD validation
Recommendation engines
Traffic routing
Security scanning

These aren’t experiments. They’re core infrastructure.

So the issue isn’t AI.

It’s how we’re using it.

The Real Problem: Autonomy Without Architecture

When someone gives an AI agent full control of deployments, scaling, configuration, and fixes, they’re not testing AI.

They’re testing a system with:

No guardrails
No constraints
No approval flow
No domain context
No separation of concerns
No safety boundaries

If you gave a junior engineer root access and told them “optimize everything,” you’d get the same result — just slower.

AI didn’t fail.

The system design failed.

What Production‑Ready AI Actually Looks Like

Production‑ready AI is not autonomous.

It is augmented.

It doesn’t replace humans — it amplifies them.

It doesn’t guess — it advises.

It doesn’t act unilaterally — it operates within boundaries.

Here’s what that looks like:

1. Clear Scope

AI handles one domain, not the entire stack.

Examples:

Log summarization
Alert triage
Deployment validation
Predictive autoscaling

Not:

“Fix anything you think is wrong.”

2. Human-in-the-Loop

AI proposes. Humans approve.

This is how:

CI/CD bots
Security scanners
SRE assistants
Code review tools

…already work today.

3. Guardrails

AI should operate inside a sandbox of:

Allowed action
Forbidden actions
Rate limits
Resource boundaries

If an agent can modify your production datavase config, that’s not AI’s fault — that’s a missing guardrail.

4. Observability

You need visibility into:

Why the AI made a decision
What data it used
What alternatives it considered
What it plans to do next

Opaque agents are dangerous. Transparent agents are powerful.

5. Fail-Safe Defaults

AI should fail closed, not fail creative.

If uncertain:

Don’t deploy
Don’t scale
Don’t modify configs

Ask a human.

Irony: AI Is Better at Production Than Humans — When Used Correctly

AI is exceptional at:

Pattern detectiom
Predicting failures
Surfacing anomalies
Analyzing logs
Identifying regressions

Humans are exceptional at:

Understanding context
Evaluating trade-offs
Prioritizing business impact
Knowing what not to touch

Production systems need both.

The future isn’t “AI replaces engineers.”

It’s engineers augmented by AI that never sleeps, never gets tired, and never misses a pattern.

Where AI Belongs in Production Today

Absolutely Ready

Log analysis
Alert correlation
Deployment validation
Code review assistance
Predictive autoscaling
Incident summarization
Security scanning
Test generation

Ready With Guardrails

Automated rollbacks
Automated scaling
Automated patching
Automated remediation (with approval)

Not Ready Without Human Oversight

Autonomous architecture changes
Autonomous database modifications
Autonomous deployments
Autonomous “optimizations”

The line isn’t about capability.

It’s about risk, context, and control.

The Bottom Line

AI isn’t the problem.

Autonomy is.

AI is already running production systems across every major industry — safely, reliably, and at scale. But the moment we hand it full control without constraints, we stop using AI as a tool and start treating it like a replacement for engineering judgment.

That’s when things burn.

The future of production isn’t human vs. AI.

It’s human + AI, working together, each doing what they do best.

What’s your take — have you seen AI shine or crash in production?

Daily Challenge #12 : The “Invisible Inputs” Form 🧾

bingkahu (Matteo) — Tue, 24 Feb 2026 08:30:00 +0000

It is February 24th. -

Quick announcement before we begin: this will be the last daily challenge. Creating one every single day has been a blast, but also a lot to keep up with. To keep the ideas fresh and the quality high, the series will now shift to a weekly format.

The next challenge will drop next week.

Now — today’s mission.

The Mission

Build a fully interactive form where none of the inputs are visible, yet the user can still complete it from start to finish.

Your job is to guide the user entirely through layout, labels, focus states, and clever CSS illusions.

The Rules 🫥

No JavaScript Pure HTML + CSS only.
Inputs must be visually hidden But still accessible and functional.
Use labels, focus states, or animations To show the user where they are.
The form must be completable Text fields, checkboxes, radios — your choice.

The Goal 🏆

Create a form where:

Inputs are hidden by default
Focusing reveals hints or context
The user can still fill out every field
The whole thing feels like a CSS magic trick

Pro Tip

:focus-within is your secret weapon.

It lets you reveal instructions, highlight sections, or animate containers when the user interacts with hidden fields.

How to enter

Drop your CodePen or GitHub Repo in the comments.

Extra Credit

If your form includes:

A CSS‑only progress indicator
A “success” state with no JS
Fully semantic HTML

—you’ve mastered invisible UX.

Good luck, have fun, and enjoy the last daily drop before we go weekly. Can’t wait to see what you build.