Skip to content

Plan foobar extension roadmap #277

Description

@sreetamdas

Foobar extension ideas

Date: 2026-06-21
Branch when drafted: feat/foobar-hardening

This note tracks future product/design ideas for the hidden /foobar achievement game. It is intentionally not an implementation spec yet; it is a direction doc for later refinement.

Current framing

/foobar already works best when it feels like a site-wide scavenger hunt, not a normal feature page. The best extensions should preserve that feeling:

  • clues should be hidden in real web surfaces;
  • solutions should reward curiosity, not just clicking buttons;
  • the dashboard should feel like a progress hub, not the whole game;
  • the game should remain optional and non-invasive;
  • accessibility/mobile alternatives should exist, even if the main path is nerdy/devtools-heavy.

Feature: difficulty tiers

Tiers are worth doing. The value is not just labeling achievements as easy/hard; tiers can shape the whole game loop.

Why tiers help

  • They give players a readable progression path instead of a flat badge wall.
  • They let easy achievements teach the rules of the game before harder ones ask for weird web knowledge.
  • They create better completion moments: completing a tier can show a small celebration before the final all-flags completion.
  • They let hints ramp differently per challenge difficulty.
  • They make the dashboard feel like a map.

Suggested tiers

Tier 1: Warmup / Discovery

For achievements that teach: “this site hides things.”

Examples:

  • unlocked — find the hidden on /about.
  • source-code — inspect page source.
  • headers — inspect response headers.
  • localforage — inspect localStorage.
  • teapot — discover /api/coffee.

Tier 2: Browser Goblin

For achievements that require browser tools or browser behavior.

Examples:

  • devtools — inspect React/devtools clues.
  • hack — run/trigger the console helper.
  • offline — go offline while on a foobar page.
  • navigator — visit five unique pages.
  • easter-egg — find a hidden interaction in regular site UI.

Tier 3: Site Archaeology

For achievements that require understanding the site structure and existing content.

Examples:

  • Find a hidden clue in RSS or sitemap-adjacent output.
  • Find a clue embedded in an old blog post footnote.
  • Find a clue in a presentation/slides route.
  • Find a clue in a specific 404 state.
  • Find a clue by comparing /stats, /about, and a dynamic content page.

Tier 4: Protocol / Web Weirdness

For achievements that require HTTP/DNS/browser platform knowledge.

Examples:

  • dns-txt — inspect TXT records.
  • Find an Accept-header-dependent clue.
  • Find an ETag/cache-related clue.
  • Find a clue only visible through HEAD or OPTIONS.
  • Find a clue in robots.txt comments or headers without letting /foobar enter sitemap/SEO surfaces.

Tier 5: Meta / Endgame

For achievements that require combining clues.

Examples:

  • completed — all slugged achievements done.
  • Decode a phrase assembled from clue-log entries.
  • Use the terminal feature to run a final command.
  • Generate the completion card.

Dashboard shape for tiers

Instead of a single “Completed challenges” grid, show sections:

Warmup / Discovery        4 / 5
Browser Goblin            3 / 5
Site Archaeology          0 / 4
Protocol / Web Weirdness  1 / 4
Meta / Endgame            0 / 2

Each tier could have:

  • progress count;
  • short flavor text;
  • collapsed/expanded badge grid;
  • tier completion marker;
  • tier-specific hint policy.

Data model sketch

Add optional metadata to FOOBAR_FLAGS:

tier: "discovery" | "browser" | "archaeology" | "protocol" | "meta";
difficulty: 1 | 2 | 3 | 4 | 5;

Keep this purely presentational at first. Do not let tier metadata control core completion logic until there is a clear need.

Feature: clue log

A clue log is a “field notes” / investigation journal inside /foobar. It should not replace badges. Badges answer “what did I complete?” The clue log answers “what traces did I notice along the way?”

Why it is useful

  • It makes the game feel more exploratory and less binary.
  • It gives partial credit: finding a clue can be fun even before solving the matching achievement.
  • It helps players resume after leaving and coming back later.
  • It creates a natural place for hint ladders.
  • It can make the final meta puzzle richer: the clue log itself can contain fragments that combine into an endgame clue.

What counts as a clue-log entry?

A clue-log entry should be recorded when the player encounters a meaningful trace, not only when they complete an achievement.

Examples:

  • Opened /foobar while locked and saw the “check the console” message.
  • Console clue was printed.
  • localStorage clue was planted/read.
  • x-foobar response header was present.
  • Source-code clue was present in root scripts.
  • Hit the /api/coffee teapot response.
  • Reached a 404 page.
  • Clicked a locked badge enough times to reveal a hint.
  • Opened the future terminal.
  • Completed a tier.

What it should look like

A compact timeline or notebook on the dashboard:

Field notes

✓ 14:02  Heard a whisper in the console.
         “To start, how /about you get to know me better?”

✓ 14:04  Found the hidden X.
         The dashboard is unlocked.

✓ 14:11  The server left a header.
         x-foobar points somewhere useful.

?        Protocol clue undiscovered.
         Hint available after 2 more attempts.

Possible display modes:

  1. Timeline — chronological, nice for “story of discovery.”
  2. Grouped by tier — better when tiers exist.
  3. Notebook pages — more playful, can include fragments/sketches.

Clue log vs hint ladder

They overlap but are different:

  • Clue log: records what the player has encountered.
  • Hint ladder: reveals increasingly direct help for a specific unsolved achievement.

A good integration:

  • Each badge has hint levels.
  • When the player reveals or triggers a hint, the clue log records that note.
  • The log can show “you have seen 2/4 clues for this achievement.”

State model sketch

Current state could grow from:

completed: FoobarFlag[];

to include:

clues_seen: Array<{
  id: string;
  achievement?: FoobarFlag;
  tier?: FoobarTier;
  seen_at: number;
}>;

Keep clue IDs stable and catalogued, similar to flags:

FOOBAR_CLUES = {
  console_entry: {
    id: "console_entry",
    achievement: "unlocked",
    title: "A whisper in the console",
  },
};

Important design constraint

Do not auto-log everything immediately just because code can detect it. The log should reflect player-facing discoveries. If the app silently plants a clue, record it only when the player performs a meaningful action or reaches a relevant surface.

Feature: hint ladder

This is still a strong yes.

Current badge behavior already has a primitive hint mechanism: click a locked badge five times to reveal its description. A richer hint ladder would make that intentional.

Example per achievement:

hints: [
  "The server may be saying more than the page does.",
  "Try looking at response headers.",
  "Look for x-foobar.",
  "Visit /foobar/headers.",
]

Rules to consider:

  • Hint 1 is free after unlock.
  • Hint 2 appears after some failed/idle interactions.
  • Hint 3 requires clicking the badge several times.
  • Hint 4 is a “just tell me” reveal.
  • Revealing a hint records a clue-log entry.

Feature: completion card

Strong yes.

A completion card is the natural endgame reward. It should be shareable, pretty, and low-maintenance.

Minimal version

Client-only card generated from local state:

  • title: “I captured all the flags”;
  • date completed;
  • badges/tier summary;
  • silly generated title, e.g. “Browser Goblin Supreme”;
  • copy/share/download buttons.

Better version

Generate a server-verifiable completion token:

  • client sends completed achievement list to a Worker route;
  • Worker validates shape, signs a compact token with a secret;
  • share URL renders /foobar/card/$token;
  • card can be verified without creating accounts.

Best version later

Persist optional public completions:

  • D1 stores token hash + created date + display name optional;
  • public “wall of goblins” leaderboard/card gallery;
  • no identity required unless the site later has a reason for auth.

Feature: terminal

Strong yes.

The terminal can become both a playful dashboard surface and an endgame mechanism.

UX concept

A terminal panel inside /foobar:

sreetamdas.com:/foobar$ help
commands: help, badges, clues, curl, dig, cat, open, whoami

Commands should be fake/sandboxed, not an actual shell.

Example commands

help
badges
clues
open /about
curl /api/coffee
curl -I /
dig TXT sreetamdas.com
cat localStorage.foobar
whoami

Why terminal is especially good here

  • It matches the existing console/devtools flavor.
  • It gives non-expert players a guided way to learn “web weirdness.”
  • It creates a unified interface for protocol-ish puzzles without making users leave the browser.
  • It can provide accessible alternatives for clues that otherwise require devtools, curl, or DNS.

Terminal achievements

  • terminal — run help.
  • barista — run curl /api/coffee.
  • header-hunter — run curl -I / and notice x-foobar.
  • cartographer — run badges or clues after unlocking tiers.
  • whoami — discover a silly identity/title.
  • root — final endgame command after all tier fragments are collected.

Rethinking Cloudflare-native achievements

The first pass of Cloudflare-native ideas was too implementation-flavored and not magical enough. “Find a Worker header” or “trigger a queue” is fine technically, but not exciting by itself.

Better framing: use Cloudflare as invisible site infrastructure that creates surprising web-native moments. The player should not feel like they are testing Cloudflare products. They should feel like the edge of the website is haunted.

Principles for better infra-backed puzzles

  • The clue should have a story/flavor, not just “this uses KV.”
  • The Cloudflare primitive should create behavior that static React cannot easily do.
  • The player action should be simple and fun.
  • The implementation detail can stay hidden until the player solves it.
  • Avoid puzzles that require a Cloudflare dashboard or vendor knowledge.

Better Cloudflare-backed achievement ideas

edge-echo

Flavor: “The site answers differently depending on where the edge hears you.”

Mechanic:

  • A Worker route returns a tiny “edge echo” response with colo/country-ish flavor.
  • The achievement does not require knowing Cloudflare; the clue says the edge has a voice.
  • Terminal command: curl /api/echo.

Example output:

heard from the edge: BOM
next: /foobar/edge-echo

Why better: it uses edge metadata as flavor, not homework.

midnight-ink

Flavor: “A note appears after midnight UTC.”

Mechanic:

  • Cron updates a KV value daily.
  • /foobar/terminal or a hidden route can read the daily note.
  • The note is part of a rotating clue/hint, not a permanent badge requirement unless designed carefully.

Why better: cron/KV creates a living puzzle. It feels like the site changes over time.

message-in-a-bottle

Flavor: “Send a message into the void; it returns later.”

Mechanic:

  • Player runs a terminal command or clicks a dashboard control.
  • A Queue processes it asynchronously.
  • The UI says “the bottle is drifting...” then later shows the clue.

Why better: the async delay is the experience. Queue is not the point; waiting for the bottle is.

campfire

Flavor: “You are not alone here.”

Mechanic:

  • Use existing presence/live infra or a small Durable Object to show anonymous current explorers.
  • Badge unlocks when the player sees another explorer, or when they keep the campfire open for a bit.

Why better: real-time presence is emotionally stronger than “Durable Object achievement.”

ghost-cache

Flavor: “A ghost of an older response is still here.”

Mechanic:

  • A cache-related route intentionally serves a harmless stale clue for a short window.
  • Terminal can expose cache status: HIT as flavor.

Why better: caching becomes a ghost story.

constellation

Flavor: “Every explorer lights one star.”

Mechanic:

  • D1 stores anonymous completion or tier-completion counts.
  • Dashboard shows a constellation with total completions, not a leaderboard by default.
  • Completion card can add a star.

Why better: D1 persistence creates community presence without turning it into analytics homework.

edge-postcard

Flavor: “Receive a postcard stamped by the edge.”

Mechanic:

  • Completion card includes a small generated stamp based on request metadata/time.
  • Not a separate badge necessarily; more like a reward detail.

Why better: infrastructure enhances the reward artifact.

Cloudflare ideas to avoid

Avoid achievements whose pitch is basically:

  • “find this Worker route”;
  • “trigger this queue”;
  • “query this database”;
  • “look at this Cloudflare-specific header.”

Those are implementation tasks, not game moments. They can exist under the hood, but the surface should be story-first.

More concrete new achievements/challenges

Discovery / Warmup

  • x-marks — find the hidden Roman numeral on /about.
  • view-source — find the source-code clue.
  • paper-trail — discover a clue in RSS/robots/sitemap-adjacent output.
  • tiny-door — find an invisible or tiny UI affordance that is still keyboard reachable.

Browser Goblin

  • storage-rat — inspect localStorage and follow the clue.
  • offline-goblin — go offline on a foobar page.
  • console-poet — trigger/read the console helper.
  • tab-hoarder — visit a set of distinct content types: blog, about, stats, slide, 404.

Site Archaeology

  • old-note — find a clue hidden in an older blog post or newsletter issue.
  • slide-secret — find a clue in a slide deck route.
  • stats-gazer — find a clue related to public stats, views, or likes.
  • dog-whisperer — solve the 404 dogs path.

Protocol / Web Weirdness

  • head-first — use HEAD/headers via terminal or devtools.
  • txt-me — inspect DNS TXT records.
  • short-wave — find a clue that appears only for a specific Accept header in terminal.
  • ghost-cache — notice stale/cache behavior in a safe route.

Terminal

  • hello-shell — run help.
  • barista — run curl /api/coffee.
  • header-hunter — run curl -I /.
  • dig-dug — run dig TXT sreetamdas.com.
  • cat-burglar — run cat localStorage.foobar.
  • root-but-not-really — run the final command assembled from clue fragments.

Meta / Endgame

  • cartographer — complete every tier.
  • constellation — add a star to the anonymous completion constellation.
  • calling-card — generate a completion card.
  • goblin-supreme — complete all achievements without using final-level hints. Optional, only if hint usage is tracked.

Suggested next build order

  1. Tiers metadata and dashboard grouping.
  2. Hint ladder data model.
  3. Clue log data model and dashboard display.
  4. Terminal MVP with fake commands for existing clues.
  5. Completion card MVP.
  6. Story-first Cloudflare-backed puzzles: campfire, message-in-a-bottle, constellation, or midnight-ink.

Do not build all of this at once. The best first slice is tiers + hint ladder + clue log using existing achievements, because that improves the current game without expanding the puzzle surface too much.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions