DEV Community: Aniq Haider

An editor update system with a human approval gate on every write

Aniq Haider — Thu, 22 Oct 2026 10:17:38 +0000

A visual editor stores each page as structured template data behind an API. Changing that data in bulk is powerful, and also easy to get catastrophically wrong. I built an editor update system around one rule: reads are free, writes are never automatic.

Safe change workflow

Every mutating call passes through the same gate. Nothing is batched under one approval.

UNDERSTAND
      API catalog  (Every endpoint recorded with a verified response shape)
  ──▶ GET and inspect  (Reads run freely to see the real data)
  ──▶ Plan the change  (Exact request body, reviewed before it is sent)

CHANGE
      Approval gate  (A person confirms each POST, PUT, PATCH or DELETE)
  ──▶ Backup first  (For deletes, save the full template JSON to disk)
  ──▶ Mutate  (One call at a time)
  ──▶ Verify with GET  (Confirm the saved shape matches the plan)

The design decisions

An isolated workspace with its own instructions, so nothing bleeds into other projects and the rules are impossible to miss.
A growing, append-only API catalog. Each endpoint is recorded with its method, whether it mutates, a working request and the response shape I actually observed.
Backup before delete is mandatory. A deleted template is saved with a timestamp, and restoring it is a single PUT of the saved page configuration.
Approvals do not carry over: a similar call approved earlier in the session does not authorise the next one.

The goal is speed without fear. Automation does the tedious inspection and bookkeeping, and a person keeps the final say on anything that changes live data.

Originally published on my portfolio.

github-repo-mcp: letting an AI explore any GitHub repo without cloning it by hand

Aniq Haider — Thu, 22 Oct 2026 10:17:17 +0000

When an assistant needs to understand a codebase it does not have locally, the usual options are pasting files or cloning by hand. I wanted something better: point the assistant at owner/repo and let it explore, the way a developer would. So I wrote github-repo-mcp, a local Model Context Protocol server.

Architecture

The server runs over stdio. Repos are cloned once and reused from a local cache.

REQUEST PATH
      Claude  (MCP client)
  ──▶ github-repo-mcp  (stdio server, written in TypeScript on Bun)
  ──▶ Local clone cache  (~/.cache/github-repo-mcp/owner/repo)
  ──▶ GitHub  (Cloned once, pulled on refresh)

FIVE TOOLS
      load_repo  (Clone or reuse, return a summary)
  ──▶ get_repo_map  (Files and exported symbols)
  ──▶ grep  (Regex search with context)
  ──▶ read_file  (A file or a line range)
  ──▶ refresh_repo  (Pull latest, invalidate the map)

How it works

load_repo clones a repo (or reuses the cached copy) and returns languages, file count, a top-level tree and a README excerpt, enough to decide where to look next.
get_repo_map builds a structural map of paths and exported symbols. TypeScript gets a fast extraction path, and other languages such as Python are parsed with tree-sitter.
grep uses ripgrep for speed and falls back to a pure-JS search when ripgrep is not installed.
A GitHub token is optional and only needed for private repos. Path guards keep reads inside the cloned repo.

The workflow it enables

Load the repo, read the map to find the right module, grep for the call sites, then read only the lines that matter. The assistant spends its context on understanding the code and not on scrolling through it.

It is a small server with a deliberately small surface: five tools, one cache directory, and tests around the guards and the parser.

Originally published on my portfolio.

A multi-agent pipeline that clones live sites into production components

Aniq Haider — Thu, 22 Oct 2026 10:16:55 +0000

Rebuilding a page section by hand means inspecting the DOM, copying design tokens, chasing hover states and fixing responsive breakpoints. It is slow, and it is mostly mechanical. I built a pipeline of Claude Code subagents that does the mechanical part and leaves the review to a human.

How a clone run flows

Sections run strictly one at a time, so each agent keeps a small, clean context.

ONCE PER PAGE
      Input  (Live URL or Figma frames)
  ──▶ Phase 0 · Discover  (Scroll, find sections, capture 4 breakpoints)
  ──▶ Pick sections  (One, several, or all)

FOR EACH SECTION, IN ORDER
      Phase 1 · Harvest  (Tokens, assets, hover and scroll behaviour, screenshots)
  ──▶ Compress  (Shrink the handoff JSON before the next agent reads it)
  ──▶ Phase 2 · Build UI  (Widget code wired into the page template)
  ──▶ Verify build  (Pass moves on. Fail retries, up to 3 times)

AFTER THE RUN
      Hill-climb  (Mine notes and failures into reusable rules)
  ──▶ learnings.md  (Read by every agent at the start of the next run)

Why separate agents

Each phase has one job and one output file (sections.json, harvest.json, the generated widget). A failed phase can be re-run without redoing the others.
The main session orchestrates instead of a nested orchestrator agent. That saves context, and I can step in between phases.
A Figma branch replaces only the discovery and harvest agents. It emits the same files, so the UI agent is reused untouched.

What keeps it reliable

A hard build gate: a section only counts as done when the project builds. Errors go back to the agent for up to three retries.
Guardrails written into the pipeline: shared directories are off limits, and protected files may only be changed by commenting out the original, never deleting it.
A learning loop. Every run's notes and failures are distilled into rules the next run reads, so the same mistake is not repeated.

The result: new sections that used to take days now take hours, and most of that time is human review instead of pixel-pushing.

Source code: a generic version of the agents is on GitHub: AniqHaider/site-clone-agents.

Originally published on my portfolio.

Cardify: restyling a storefront's product cards without touching its code

Aniq Haider — Thu, 22 Oct 2026 10:05:10 +0000

Every merchant eventually asks the same thing: "Can our product cards look different?"

On a commerce platform, that request is more expensive than it sounds. A product card is not one component. It shows up in collection grids, carousels, search results and related-product rows, and each of those widgets renders its own markup. Changing the look of a card means touching all of them, for every storefront that wants it.

I built Cardify to avoid that. It is an app that restyles product cards from the outside. The merchant opens an admin screen, flips a switch, picks one of five designs, and the storefront's own cards are replaced live. No storefront redeploy, no page reload, no edits to the widgets that render the cards.

It is now running in production on 16 storefronts on the Ratio platform.

How a card gets replaced

The storefront exposes only a few data attributes on its native cards. Everything else is loaded on demand. There are three flows to understand: setup, what happens on the storefront, and what happens when a shopper clicks.

SETUP (merchant)
  Merchant admin ──▶ Settings API ──▶ Public config
  React + Vite       Fastify + MySQL   Read-only endpoint
  switch on, pick    admin writes are  the storefront
  design + colours   key-protected     loader calls

ON THE STOREFRONT (every page load)
  Tiny loader ──▶ Config says off? ──yes──▶ do nothing, native cards stay
  0.5 KB gzip          │
  fetches config       no
                       ▼
                  Load widget ──▶ Overlay
                  ~10 KB gzip,    hide each native card,
                  imported lazily mount a Cardify card in its cell

WHEN A SHOPPER CLICKS
  Cardify card ──▶ Hidden native link ──▶ Store behaviour runs
  click or         click is delegated     routing, quick-buy popup
  quick-buy        to the store's own     and analytics, unchanged
                   element

The important part is the second flow. The loader is tiny, about half a kilobyte gzipped, and its only job is to fetch the merchant's config. If Cardify is switched off, it does nothing and the shopper never downloads anything else. If it is on, the widget, about 10 KB gzipped, is imported lazily, hides each native card and mounts a Cardify card in the same cell.

Design choices that matter

Purely cosmetic. A Cardify card uses exactly the data the native card already renders. There is no new data contract for the storefront to maintain, which is a big part of why it can be dropped onto a store without a conversation with that store's developers.
Native cards are hidden, never removed. The overlay mounts inside the same cell, so the store's grid and carousel layout stays untouched. A MutationObserver picks up cards that appear later, such as items loaded by infinite scroll or a filter change.
Behaviour is delegated back to the host. When a shopper clicks a Cardify card, it clicks the hidden native link. The store's own routing, quick-buy popup and tracking keep running exactly as before. Cardify never has to reimplement any of it.
It fails safe. If the backend is down, the config call errors or the bundle is blocked, the shopper simply sees the original cards. The worst case is "Cardify did nothing", never a broken product grid.
No polling. The config refreshes on page load and when the tab regains focus. A timer would make every visitor's open tab hit the backend, for no benefit.
The server refuses to start without an admin key. A missing environment variable can never silently mean an open admin.

Five designs, one structure

The five designs are classic, minimal, overlay, hover-reveal and editorial. They all share one DOM structure and differ only in CSS. That is the reason click and quick-buy bridging works for every design for free: the elements the bridge looks for are in the same place in all of them.

Merchants can tune accent, text and background colours, corner radius and image shape, and toggle the badge, quick-buy, rating and compare-at price. Every setting is validated with a shared zod schema, used by both the admin and the API, so the two cannot drift apart.

Adding a sixth design is a registry entry plus one CSS block.

Status

Cardify is live in production on 16 storefronts. It is covered by unit tests and a headless-Chromium end-to-end suite that runs the real overlay against mocked storefront pages.

The stack: Lit for the storefront widget, Fastify and MySQL for the API, React and Vite for the admin, and Playwright for the end-to-end tests.

If you are building something that has to live inside someone else's page, the lesson I would pass on is this: hide, don't remove, delegate instead of reimplementing, and make every failure path end in "the original page, unchanged".

Source code: a lightweight, self-contained version is on GitHub: AniqHaider/cardify-lite.

Originally published on my portfolio.