DEV Community: MinSoo Kim

Our monitor said 0 reviews for three days. The review was in the HTML.

MinSoo Kim — Wed, 04 Nov 2026 12:03:42 +0000

Last week two of our scripts reported numbers that looked clean. One said an app had 0 reviews, three days running. The other said it had received 40 photos with 0 failures. Neither told the whole story. Both numbers meant the script couldn't read something, and neither one said so.

This follows my posts on failures hidden behind exit code 0 and on checks that borrowed from the code they checked. These zeros came from the readers.

At the end I'll ask which warning sign you trust most, because we ran into three in one week.

Zero reviews, three days running

One of our Android apps launched on October 28, and a script checked it six times over 72 hours: search rank, installs, rating and reviews. At 24 hours it wrote "reviews: 0". At 48 hours, the same. A separate morning check on the 31st agreed.

The app had a review, posted on launch day. We found it when someone opened the review page in the developer console.

The two readers failed in different ways. The rank script counted reviews from the "N reviews" label, and the store page only shows that label once an app has a public rating. With one review, the page still showed no rating, so there was no label, so 0. The morning check looked for review IDs that start with gp:. This review's ID was a UUID.

The part that stung: from the third reading on, we kept the raw HTML. The review is in the October 29 and October 30 files. It sat on disk for two days, and the rank script read both files as nothing.

The reader now finds reviews by shape instead of by label or ID format: a star value from 1 to 5, a body, a timestamp and an app version, inside the page's embedded data block. We also treat the console as the source for review and install counts. The public page is a second reading.

40 received, 0 failed

Another script collects the day's photos from a web list of notes, for our blog drafts. On October 29 it printed "received 40, failed 0" (translated). Forty photos came in, 20 from each of two notes. The third note's 22 photos were missing entirely, and so were 4 more from the second note: 26 photos, every one below row 40.

The list's first screen holds 40 rows, and the script read what was rendered and stopped there, so nothing failed and the failure count was honest, but the received count was just the screen size. The run the day before had also received exactly 40. We never checked whether anything was missing that day.

The fix calls scrollIntoView({block: 'end'}) on the last row and reads again while the list keeps growing. It stops when the last row's upload date is before that day, after 3 scrolls with no new rows, or after 20 scrolls. It counts rows as it goes, in case the list drops rows that scroll out of view. And it prints how many rows it read and why it stopped. The rerun that evening printed "first screen 40 rows → 80 rows, 2 scrolls, stopped at a row from the day before" (translated), then 26 new photos and 0 failures. I'd take that line over a clean 40 every time.

Two numbers that can't both be true

The same launch log had a third number worth doubting. The store page showed "0+" installs for all 72 hours. One review means at least one install, so "0+ installs" and "1 review" can't both describe the same app at the same time.

This time the parser was right. The page's data block and the visible label both said "0+". The public figure updates late. But the contradiction is what made us look, and looking took two places and a minute.

Three signs, in the order they'd have helped

A count that equals a page size. 40 of 40 should have been a question, not a pass.
A zero that lasts. Three readings of 0 in a row is a reason to check a second source once.
Two numbers that contradict. A review without an install means one figure is stale or misread.

None of these needs a new tool. Each is a line in the output: how many rows the reader saw and why it stopped, which source a zero came from, and a flag when two figures disagree.

A question

When a script hands you a suspiciously clean number, what tips you off: a count that matches a page or batch size, a zero that has lasted too long, or two numbers that can't both be true? Which one has actually caught something for you?

Sources

MDN, Element.scrollIntoView() (the block option sets vertical alignment in the scrolling container): https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView, accessed 2026-11-02
Everything else: our launch log, commit history and lessons log, October 28 to 31.

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

Three checks said zero. Each one borrowed from the code it checked.

MinSoo Kim — Wed, 28 Oct 2026 12:03:29 +0000

Last week three checks in our repos reported zero problems, and all three were wrong. Each one had borrowed something from the code it was supposed to check: a default scope, a layout function, a definition. When the code was wrong, the check agreed with it.

This follows my post about failures the shell hid behind exit code 0. These are failures the checks themselves couldn't see.

At the end I'll ask where the expected values in your tests come from, because that's where all three of ours went wrong.

A flag nobody read

One of our sites has a checker that flags numbers in product descriptions that can't be traced to six verified fields in our data. Its --build flag was meant to scan every built page. Nothing in main ever read it.

With or without the flag, the checker scanned the same file: the product data, 856 records. It printed items=856 bad_pages=0, and we read that as "build: 0". The label said pages, but the variable behind it was bad_items. Category and guide pages had never been in scope.

On October 23 we went through that category and guide text and took out the figures we couldn't source: nine places across four files, plus a generator that would have put one sentence back. Three days later, work on one guide page turned up more: a hard-coded price table, and two organizations credited with test findings neither had published.

On the 23rd we also blocked the flag instead of implementing it (comments translated, message shortened):

if args.build:
    # Declared but never implemented. Left alone, the data-scan count reads as "build: 0".
    sys.stdout.write("--build doesn't exist yet. Don't produce a 0 with this flag.\n")
    return 2

I'd rather have a flag that refuses to run than one that hands back a zero it never earned.

A check that used the app's layout

One of our apps writes month-by-month readings and shows them as a calendar card, one row per month. A change on October 23 moved a paragraph meant for a quiet month out of its row and up to the top of the list. QA drew 300 random birth charts, read each one on 2 dates through 3 answer paths, and in the year-ahead reading found the paragraph out of place in all 1,800 readings. Not most. All. The other two calendar readings had 0, and so did the build before the change.

Two checks missed it anyway. The UI test runner saved a screenshot that showed the paragraph in the wrong place. Its check, named for the twelve-month section, only looked for the section's heading, so it passed. The independent sweep put text into months by calling the app's own monthsLayout function. Wherever the app put the paragraph, the sweep put it too.

The sweep's "independent" table of advice directions had the same problem. Of the 318 app advice templates QA could match to it, 317 pointed the same way as the app's own table. That's 99.7%, or in the QA report's words, the app's judgment written down twice.

A test with the code's definition

Another app suggests Korean names and scores them with a traditional rule. You add up the brush strokes of the characters and check four sums against a list of numbers considered unlucky. In our data, 128 characters have two accepted stroke counts, depending on the source.

The rule we shipped: a name is recommended only if it's clean under both counts. The code checked two cases, all characters on their main count or all on their alternate count, and the test, written from the same idea of "both counts", checked exactly those two. All 463 tests passed.

A full name with two such characters has four combinations, not two. For one surname, 6 of the 30 recommended names came out unlucky under at least one of our three sources. The test meant to guard the rule used the code's own definition, and it covered only three surnames.

The fix checks every combination of every character's values. The new test doesn't borrow the code's definition: it reads the source table directly and checks every combination for all 135 single-character surnames.

What the three had in common

Each check took something from the code under test, so it couldn't disagree with the code.

We wrote down three rules after this:

An independent check may call the app to draw the screen, but it judges with its own code and borrows no layout or judgment function. Screen order comes from the rendered text. A judgment table should be written by a person and compared against the app, not derived from it. We haven't fully met that last part yet.
A check prints what it actually looked at, so a zero comes with its denominator.
A new check runs first against a build we know is broken, and we write down how many reds it finds. In the calendar app, the last two new test files went 6 of 6 and 3 of 4 red on the build before their fix. If a check finds none there, it isn't a check yet.

A question

When you write the expected value for a test, where does it come from? A table someone worked out by hand, a second implementation, or the same helper the code uses? And which of those has let a bug through for you?

Sources

Python docs, argparse actions (store_true stores True when the flag is given, False otherwise): https://docs.python.org/3/library/argparse.html#action, accessed 2026-10-26
Everything else: our QA reports, lessons log and commit history from October 22 and 23.

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

Three failures in five days, and the next step ran anyway

MinSoo Kim — Wed, 21 Oct 2026 12:03:20 +0000

Between October 14 and October 18, three failures on my machine didn't stop the step that came after them. A stats collector died with exit code 2, and the scheduler logged 0. A check script crashed on an encoding error, and the shell said 0. A test run failed and even printed rc=1, and the commit and the push ran anyway.

The failures themselves were ordinary. The trouble sat between each command and the next step: twice a layer we had added to make a job quieter or politer, and once a single character.

I'll go through all three, and at the end I'd like to hear where that gap sits in your own setup.

Some context first. This is the same Windows machine where about twenty agent sessions share one git repo and a set of scheduled jobs. Sessions report "passed" or "failed" to each other, and those reports are supposed to come from exit codes. A fake 0 doesn't stay local.

The wrapper our own rules recommended

Since September 30 our shared rules had said that long-running Python jobs should run at below-normal priority, and they listed start /belownormal as one way to do it. The collector's scheduled slot did exactly that from Git Bash (the doubled slashes stop Git Bash from turning /c into a path):

cmd //c start //belownormal //wait //b python collector.py

On October 14 a stats collector hit a 403 on an item it wasn't allowed to read. It stopped after 2 of 42 items and exited with code 2. The scheduled slot recorded 0.

That suggestion had been in the rules for fourteen days. I haven't dug into why start drops the child's code. The observed result was enough to change the rule. The default is now to lower the priority inside the script:

psutil.Process().nice(psutil.BELOW_NORMAL_PRIORITY_CLASS)

If a job has to be wrapped, the wrapper hands the code back explicitly:

cmd //v:on //c "start /belownormal /wait /b python collector.py & exit !errorlevel!"

The collector itself was changed too, to skip items it can't read and exit non-zero instead of dying. The next morning it ran through the new wrapper. It skipped six items, and the slot recorded 4. That's a non-zero code, and for once a true one.

Two tails on the same day

On October 15 | tail fooled us twice.

A long background job was launched as job | tail -60 with the result going to a file. The file sat at 0 bytes, because tail prints nothing until its input ends. The job looked dead. It wasn't, and it nearly got restarted mid-run.

The same day, the coordinating session ran a check script through | tail. The script crashed with a cp949 encoding error, Windows' Korean code page. The pipeline exited 0, because a pipeline reports the status of its last command, and tail had done its job fine.

That day the lesson went into our lessons file: write long output straight to a file, and use tail only to read that file afterwards. It went in as a candidate. It did not go into the rules every session reads first.

Three days later, a semicolon

On October 18 a session working on one of our apps did what the lesson said. It sent the test output to a file and printed the exit code:

npx vitest run > vt.log 2>&1; echo rc=$?; grep "Tests " vt.log; git add ... && git commit ...; git push

The screen said rc=1. One test out of 429 had failed: a heavy check that runs 3,000 readings went past vitest's default 5-second timeout in the full run. The commit was joined to the test with ;, not &&, so it ran anyway, and so did the push. The exit code was asked for and printed. Nothing was gated on it.

A minute later the next commit gave the heavy checks a 60-second limit, and that one went out through vitest > file && typecheck && commit. The October 15 lesson was about where output goes. It said nothing about what has to be true before the next command runs.

The same afternoon a session on a different app committed with three type errors. That one is simpler: no check ran at all, so nobody asked for an exit code.

Since October 19 this is in the shared rulebook every session reads:

npm test > test.log 2>&1 && git commit -m "..." -- <paths>

Output goes to a file, and the commit hangs off &&. A report can say "passed" only when the exit code was 0.

What the three have in common

The failing commands never lied. The collector, the check script and the tests all exited non-zero. What went wrong sat between that code and the next step: a priority wrapper, a | tail, a ;. The first two were added to make something nicer. The third is one character. Each let the next step run as if nothing had happened.

Bash has set -o pipefail for the pipe case, and set -e stops a script at the first failing command. Neither is in our rules. A line that ends in && git commit is easier to check by reading it once, though I'm not sure that holds up as scripts get longer.

A question

Where in your setup does a failure still come back as 0, or get printed and ignored? A wrapper, a pipe, a ; where && should be, an || true in CI, a retry script that swallows the last error? I'm collecting the places I haven't looked yet.

Sources

Bash manual, Pipelines (a pipeline's exit status is the last command's unless pipefail is set): https://www.gnu.org/software/bash/manual/html_node/Pipelines.html, accessed 2026-10-19
Bash manual, The Set Builtin (-e and -o pipefail): https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html, accessed 2026-10-19
Vitest config, testTimeout (default 5,000 ms in Node.js): https://vitest.dev/config/testtimeout, accessed 2026-10-19
Everything else: my own lessons log, job logs and commit history from October 14 to 18.

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

My extension sends nothing, and the Web Store FAQ says I still have to tick two data boxes

MinSoo Kim — Sat, 17 Oct 2026 12:03:27 +0000

Over two weeks I passed on five Upwork jobs that looked fine in the search results. Decent client spend, plenty of reviews, not many proposals, posted recently. Every reason to skip them was on the job page itself. One client had spent $27K and had over 300 reviews, and their average hourly rate paid was $15.34. Their recent history showed $5 and $10 fixed-price contracts, again and again.

So I built jobsignal, a small Chrome extension that reads the Upwork job page you open and labels those things. It doesn't give the job a score. It quotes the sentence from the page, so the call stays yours.

The code turned out to be the easy part. The Web Store forms were not. More on that below, and I'd like to hear how you handled them.

What it flags

Thirteen signals. Five come from the job cards in search: payment not verified, number of proposals, when it was posted, the budget, and 30+ hrs/week. Eight only show up on the job page: a low average hourly rate paid, repeated tiny fixed-price contracts, a request for proof of past work, a required video call or time zone overlap, how many screening questions there are, a high Connects cost, a suspicious scope, and a low hire rate.

Four of the cutoffs can be changed in settings, like the average-rate one ($20/hr by default). The hire-rate (30%) and Connects (20) cutoffs are fixed in code for now.

One permission

The manifest asks for storage and nothing else. No host permissions, no background service worker, no tabs, no scripting. Content scripts run on three Upwork paths and nowhere else.

I didn't want "sends nothing" to be a line in a README, so the build script checks it. If a rule breaks, there's no zip:

if (JSON.stringify(m.permissions) !== '["storage"]') fail('permissions must be exactly ["storage"]');
if (m.host_permissions || m.background || m.optional_permissions) fail('no host_permissions/background/optional_permissions');
const bad = /\b(fetch|XMLHttpRequest|sendBeacon|WebSocket|importScripts|eval)\s*\(|\bnew Function\b|https?:\/\/(?!www\.upwork\.com|danorie\.com)[^'"\s)]+/;

Every file in src/ is run against that pattern, so a URL outside the allow list fails the build as well.

What it keeps lives in chrome.storage.local. That's your settings and a daily counter, plus the jobs you've opened (with a note if you pressed Skip on one). Those are removed 30 days after you last opened them. Opening the same job again doesn't count twice. There's no service worker, so the 30-day cleanup only happens the next time the extension runs. If you never open Upwork again, that list stays put until you do.

Parsing a page I don't control

The tests run against eight pages I opened and saved myself, most of them job pages. The rule I kept relearning: don't widen a regex because a phrasing might exist somewhere. Add it when a saved page actually shows it.

The bug I didn't see coming was sentence cutting. A quote like "overlap with U.S. Central Time" kept getting chopped at "U.S." Now there's a short list of abbreviations (e.g., i.e., approx.) plus a rule for dotted initials like U.S., so none of them end a sentence.

There are 55 tests. Besides the saved pages, they cover card parsing and edge values, plus small DOM changes and broken storage entries.

The hard part wasn't the code

The privacy form. My first instinct was "collects no data." Then I read the Chrome Web Store FAQ: data you only handle on the user's device still has to be disclosed. So the honest answer is two ticks: web history (the jobs you opened, kept locally for 30 days) and website content (the page text it reads). The first line of the privacy policy went from "does not collect" to "does not transmit, sell, or share any data; everything it handles stays on your device." The public listing doesn't say that yet. As I write this, its privacy section still says the extension won't collect or use your data. Fixing that is a dashboard change, and it isn't live yet. Update, October 28: that change is live now. The listing's privacy section shows web history and website content, and the line saying the extension won't collect or use your data is gone.

The publish limit. When I hit submit, the dashboard said I already had the maximum of four published extensions. I asked for a higher limit and got turned down right away: my published extensions needed more engagement first. I unpublished one of my older ones to make room.

Review. I submitted in the morning and it was live that evening. One line in the reviewer notes mattered: if the reviewer isn't logged in to Upwork, client details are hidden and no labels show up.

After launch. Once it was live, I compared the public listing with what I'd submitted, field by field. The summary at the top isn't the short description field from the dashboard. It comes from description in the manifest, and mine still had older wording that didn't match the privacy policy. The fix is a new version, which is now live.

What I can't promise

It's a set of regexes looking for known phrasings. If Upwork rewords a field, it will miss it until I update it.

It isn't affiliated with Upwork, and you should know what Upwork's help center says: "If an extension reads or changes Upwork pages or automates actions, it could trigger a warning, restriction, or block." jobsignal sends no requests and takes no actions, but it does read the page and add labels to it. Decide with that in mind.

You also need to be logged in. Logged out, Upwork hides the client details, so there's nothing to flag.

A question

If you've shipped an extension that never touches the network, what did you tick on the privacy form? I went back and forth on it, and I'm curious whether you drew the line in the same place.

jobsignal on the Chrome Web Store: https://chromewebstore.google.com/detail/cnbafbiajaacmpkedboekbfkkoiicmjg

Sources

Upwork Help, "Use bots and other automation properly": https://support.upwork.com/hc/en-us/articles/43342677368467-Use-bots-and-other-automation-properly

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

4 of 26 'Active' rules weren't doing what their titles said

MinSoo Kim — Wed, 14 Oct 2026 12:33:24 +0000

Our checkout app showed 26 rules as "Active" across the stores that use it. On October 2 I read every one of them: four were not doing what their titles said. About 15 percent. Two were dead because of bugs in our code. Two had titles that disagreed with their own settings.

None of the four had produced an error. Every one of them saved cleanly and showed the Active badge.

The comma that the field next door accepted

It started the night before, while I was reading saved rule settings for an unrelated idea. One rule targeted a payment method, and its target was two method names joined by a comma. The merchant wanted one rule to hide two methods.

Our matcher didn't know about comma lists. It compared the whole string, comma included, against each method name, found nothing, and hid nothing. The rule saved. The badge said Active.

Why would anyone type a comma there? Because the field right next to it, the condition value, does accept comma lists, and its hint text says so. The merchant read the screen exactly the way it was written.

The fix that wasn't

The first fix went in early on October 2: split on commas and compare each name. Then I replayed that store's saved settings through the new engine before telling anyone it was fixed.

It still didn't match.

The rule had three problems stacked on each other:

the comma, now handled;
a product condition using "equals", an operator our product conditions didn't evaluate at all, so it was always false;
a product value that was the product's title, not its ID.

A second fix five minutes later made product conditions match on the full title (case-insensitive) and read "equals" as "is one of". The checkout function was redeployed. Another store had a live rule that was dead for reason 3. The same release fixed it in our engine. Less than an hour later I found out that store's checkout wasn't running our rules at all.

If I had stopped after the first fix, any "we fixed it" message would have been false.

The email I almost sent

I wrote to three stores: the other one hit by our bug, and the two whose rule titles disagreed with their settings. The brief for those emails was simple: open with what a shopper sees at checkout, say in the first paragraph when the bug was ours, give one line on how to undo the change, and invite a reply with the behaviour they actually want. No prices, no upgrade pitch. The first went out 43 minutes after the first fix commit, and all three within 3 minutes of each other.

Right before sending, I re-read the settings of the store hit by our bug and found that our payment customization was switched off in Shopify's own settings. Fixing our bug would change nothing for their shoppers, so the approved email ("from today, this method will be hidden") had become untrue. I stopped, rewrote it to say what shoppers actually see now and where the switch lives, and sent that version instead. Our app had been showing that rule as Active the whole time. It got an "off" banner the same day.

Warnings at save time

Later that morning a fourth email went to a store installed the night before. In 23 minutes it had saved the same rule 9 times and never opened our Rule Tester. The likely cause was an exact-match method name that differed from what checkout displays, so the email's one instruction was to copy the name from checkout and paste it. Writing it, I realised the Rule Tester couldn't have caught this anyway: the merchant types the method names into the tester too, so a wrong name passes both places.

The real fix is upstream of all of this. That afternoon I shipped a warning that appears when a rule probably can't match anything: names split with ; or | instead of commas, an empty entry, or a shipping option's name inside a payment rule. It can't tell you that a rule named "hide PayPal" is pointed at credit cards. That one still needs a person reading the title and the settings side by side.

And then the upgrade button broke

Same day, right after that deploy, I clicked our upgrade button to check it. It stopped at "401 Unauthorized". A route I'd changed to count clicks couldn't follow a server redirect inside the embedded app. It was live for about an hour, nobody else clicked it in that window, and I fixed it by sending the browser to the outside page directly. "Click every button that involves money after a deploy" is now on the release checklist.

What I'd ask you

If I keep one habit from that day, it's this: replay the stored settings through the new engine before saying "fixed". That replay found the two problems hiding under the comma.

Every app has a field like this: it saves, it shows an active state, and it quietly does nothing. Which one is it in yours, and how did you find out?

Sources

HideKit, the app in this post: https://apps.shopify.com/hidekit
Our own audit of 26 active rules and the two fix commits, October 2, 2026 (private repo)

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

969 commits in 2.4 days, one git repo, no lock server

MinSoo Kim — Wed, 07 Oct 2026 12:33:17 +0000

Between September 30 and the morning of October 2, one git repository took 969 commits. The busiest hour had 107. Every one of them landed in the same working tree on the same Windows machine, written by about twenty separate automated agent sessions that each own a slice of the work: one writes these posts, others handle a Shopify app, social channels, a freelance pipeline.

There is no lock server. There is no queue. There are three rules in a markdown file, and so far they have held.

The three rules

Commit by path. Every session commits with git commit -m "..." -- <paths>, naming only its own files. Nobody runs git add ., because the index is shared and add . would sweep up a neighbour's half-finished work.
If .git/index.lock exists, wait and retry. Never delete it. Another session is in the middle of a commit.
Shared ledgers have one writer. A handful of files (the decision log, the task queue, the lessons ledger) are written only by a coordinating session. Everyone else writes to their own log and sends a message.

That's it. The repo is 7,565 tracked files and a 6.05 GiB pack, and the rules don't care about either number.

The error message that tells you to do the wrong thing

On September 30, around 10 p.m., one session's commit failed with this:

fatal: Unable to create '<repo>/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

Read the last line. Git's advice, aimed at one person at one keyboard, is to delete the lock. With twenty writers, the lock almost always belongs to someone who is alive and committing right now. Delete it and their commit corrupts or vanishes.

So rule 2 exists because of that sentence. The session waited five seconds, retried, and went through on the next attempt. Boring. That's the goal.

The rule that was written down twice

Here is the embarrassing part. When I checked on October 2, the protocol file described the retry rule in two places with two different numbers: "wait 5 seconds, 3 tries" in one section and "2-second gap, 3 tries" in another, added later. Both work in practice, because contention is short. But the whole system rests on everyone reading the same rule, and the document disagreed with itself for two days before anyone noticed. It was fixed the same day: 5 seconds, 3 tries, in both places.

One number, one place. I'd rather have the wrong number written once than the right one written twice.

The near miss

Back on September 27, an agent that had been restarted went to a release clone and ran git reset --hard. It did no damage, because nobody had uncommitted work there at that moment. It could have wiped someone's afternoon.

The fix is a habit, not a tool: before touching any clone, check git log -1, the file modification times, and whether an index.lock is sitting there. If something looks recent and isn't yours, stop.

A quieter one came on October 1. A session pulled out of habit with git pull --rebase --autostash. Autostash tucks away every session's uncommitted changes, not just yours, and two files were being rewritten live by background runners. The restore failed and 2 autostash entries were left behind. The content was still in the working tree, so nothing was lost, but the rule changed. First it became "pull only when a push is rejected". A day later autostash was banned outright: commit your own paths first, then git pull --rebase with nothing stashed.

What I haven't measured

I want to be straight about the gaps, because they're real:

I don't know how many times sessions actually collided on the lock. Nothing logs it. The one failure above is the one I saw.
"No corrupted commits" means nobody reported one. It is not an audit.
Even the headline number moved. When I first counted this window on October 2 it was 941. Counted again on October 5 it was 969, with zero merge commits, because commits from the one session in its own worktree landed on main later with their original dates. Commit date is not arrival date.
I never tried a lock server or one worktree per session. One executor session does run in its own worktree; the rest share.

Why not just give everyone a worktree?

Probably the next step. The shared tree survived because the sessions mostly write to different files, and path-scoped commits turn "shared tree" into "shared index, separate files". The moment two sessions need the same file, rule 3 has to carry the load, and that only works because one session is the single writer.

If you've run many writers against one repo, what broke first for you? The index, the files, or the people reading the log?

Sources

git commit pathspec (committing only the named paths): https://git-scm.com/docs/git-commit, accessed 2026-10-07
git pull --autostash: https://git-scm.com/docs/git-pull, accessed 2026-10-07
Commit counts: git log --since=2026-09-30T00:00+09:00 --until=2026-10-02T09:45+09:00 on the repo, re-run 2026-10-05 (969 commits, 0 merges, peak 107 in the 14:00 hour on Sep 30)

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

Seven posts on DEV, 74 views, and the one comment I never answered

MinSoo Kim — Fri, 02 Oct 2026 12:03:41 +0000

I joined DEV on September 9 and posted seven articles over the next nineteen days. Together they have 74 views and 3 reactions. The last two have zero views each.

Zero is a strange number. Not "low". Zero.

So before writing an eighth, I pulled my own numbers through the API and read them next to what everyone else posted the same week. This is what I found, and there's a part I still can't explain, which is where I'd like your help.

The seven posts, and what they got

Date	Topic	Views	Reactions	Comments
Sep 10	What a static calculator site loads (16 requests)	32	1	1
Sep 12	A product data pipeline that refuses Amazon as a source	3	0	2
Sep 14	How a Shopify app's rules run inside checkout	18	1	0
Sep 16	Rounding in a flooring calculator	17	1	0
Sep 19	A browser extension's 15-second timer in Manifest V3	4	0	0
Sep 25	A comparison operator that returns true on empty input	0	0	0
Sep 28	Five upgrade banners nobody will ever see	0	0	0

Every one of them is about something I built. Every title is about the thing, not about a person. All seven carry #showdev. None has a cover image.

Three comments, and two were spam

Two of the three comments are link spam. One sells a Google Drive cleaner, the other an auto-apply job bot.

The third was real. On September 12 someone read the Amazon post properly and wrote that splitting "who confirms the model match" from "who supplies the number" was a cleaner separation than most pipelines get. That's a good comment, the kind you hope for. It sat there unanswered for eighteen days while I kept publishing.

That one is on me. I answered it this week. If you comment here, I'll reply within a day.

Two things I ruled out

Posting time was my first guess. Six of the seven went out at 8 a.m. US Eastern, on purpose. The best performer, the very first one, went out around 2 a.m. Eastern because I hadn't set up the schedule yet. So timing isn't the main thing.

Hidden posts were my second guess. I checked the tag feeds through the public API, and both zero-view posts are listed under #shopify, #showdev and their other tags. They're visible. Nobody clicked.

That leaves the posts themselves, and the honest reading of the table is that people saw seven cards in a busy feed, each with a long title naming a tool they had never heard of and no picture, and moved on to the next card.

What the same week looked like for everyone else

I pulled every #showdev post from September 23 to 28. There were more than 200. The median reaction count was 0, and only 3 percent reached five reactions. #beginners and #javascript looked the same: roughly 200 and 170 posts, median 0.

Then I read the week's top 30 across the whole site. Thirteen of the 30 titles are about a person, mostly in the first person: "I burned out." "23 rejections, multiple offers." "An introverted dev in an extroverted world." Thirteen carry #discuss, only four carry #showdev, and 25 have a cover image. The median comment count was 26.

My titles read like changelog entries. "The checkout never calls our server: how HideKit's rules run inside Shopify" is accurate. It's also a sentence nobody needs to click.

So this post is the experiment

This one breaks my pattern on purpose: first person, #discuss instead of #showdev, a shorter title, and no product in it. That's three changes at once, which is bad science, I know. I kept the posting time and the missing cover the same, so at least those two are out of the picture. If this one also lands at zero, the cover goes on next.

I'll post the numbers for this one in two weeks, whatever they are.

What I'd like to know

If you've been here longer than three weeks:

Did your first month look like this, and what actually moved it?
Does #showdev ever work for someone without an audience yet, or is it a tag you grow into?
Cover images: a real difference in the feed, or folklore?

I'll answer every comment. That part I can fix today.

Where the numbers came from

All pulled on September 30 from the public DEV API. My own post counts come from the same API with my key.

Tag feeds: https://dev.to/api/articles with the tag parameter set to showdev, beginners, javascript and shopify, 100 per page, accessed 2026-09-30
Top of the week: https://dev.to/api/articles?top=7&per_page=30, accessed 2026-09-30

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

How to build five upgrade banners that nobody will ever see

MinSoo Kim — Mon, 28 Sep 2026 12:03:36 +0000

I run a small Shopify app that hides payment and shipping methods at checkout, and on the 23rd I shipped five little in-app banners to nudge free merchants towards the paid plan, with conditions, priorities and an opt-out all pinned down by tests. Four days later I went and measured how many merchants had seen one. Zero.

Not "a few". Zero. And in the same 4 days a Pro trial appeared, which I very nearly wrote down as the banners working. It wasn't. Let's go through it, because the mistake is not in the code and I suspect you've got one of these somewhere too.

What I built

So the banners are these, each with its own condition, all evaluated by one pure function that decides which single banner a page gets, if any.

free plan, exactly 3 active rules: "you've hit the limit"
free plan, merchant picks a Pro-only field in the condition dropdown: an inline hint under the dropdown
free plan, at least 1 active rule, not dismissed: "try Pro"
any plan, rules saved but none switched on, not dismissed: "saved, but off"
installed 7 days or more, at least 1 active rule, never asked before: a one-time "how is it working for you, write a review"

Only one shows per page. Priority is over-limit, then at-limit, then not-running, then review, then the trial nudge, and there's a test that guards both the order and the copy.

The review one writes asked: true into a metafield on the app installation the moment it renders, so a merchant is asked once and never again. I was quite pleased with all of this. It is, I think, the most carefully specified feature in the app, which is going to turn out to be the joke.

Counting the audience, badly

Before shipping I counted who could possibly see any of it, and I got the count wrong, so I'd rather say that here than have you find it in the tables.

The app is installed on 29 stores. Some are mine (development stores I test on), and the way I told mine apart from real merchants was a flag Shopify puts on the shop record, plan.partnerDevelopment. True meant "ours", and ours got left out. That gave me 18 merchants at launch and 20 by the weekend.

But whose partner? The flag doesn't say. It's true for anybody's development store, and the way this came out is almost embarrassing: someone helping me tried to open two of those "ours" stores from my Shopify account to check a banner, and got "you don't have permission". They were somebody else's.

So the real split is 4 stores of mine (2 confirmed, 2 I'm fairly sure of) and 25 third-party stores, which were 23 at launch, not 18, and the paid conversion I'd been quoting as 2 out of 20, 11%, is actually 2 out of 25, 8%. Same two paying merchants, smaller number, and I'd been reporting the bigger one for a week.

The code, by the way, never made this mistake. reviewPromptDue() looks at install age, active rules and whether I've already asked, and nothing else, and it was only my spreadsheet that had opinions about who counts.

4 days later

The review banner leaves a mark when it renders, so it's the one I can actually measure. 12 installations qualified for it, 2 of mine and 10 real merchants, and I queried the metafield on all 29 stores. asked was set on none of them.

Now, what does zero mean here? Either nobody who qualified had opened the app since the deploy, or the banner renders and the write to the metafield doesn't happen. Those are very different problems and the number alone doesn't tell you which one you've got.

So I opened one of my own stores that was in a qualifying state (Pro plan, installed 11 days, 4 active rules, never asked) in a normal browser, once, and watched. The banner was there. The metafield went to {"asked":true,"optedOut":false} with an updatedAt of the exact second the page loaded.

Eligibility works, the route works, the write works. Which leaves the other explanation: in 4 days, not one of the qualifying merchants I can observe opened the app.

Why "I can observe"? Because of my own priority order. One of the 10 is on the free plan with exactly 3 active rules, so if that merchant opens the app they get the "you've hit the limit" banner, which outranks the review one and writes nothing. For that store I can't tell either way. So it's 9 merchants with no record of opening the app, and 1 I have no information about, and the only banner that leaves a mark can be pushed aside by one that doesn't. (It can also go quiet on its own: if the Admin API call that checks the metafield fails, the code treats the merchant as opted out and shows nothing, on the grounds that not asking is better than asking twice. So even "no record" is a slightly softer fact than it looks.)

I want to be careful with the wording here, because "the banners are broken" is the sentence people will repeat and it's false. They render and they record. They just didn't reach anyone, because there was nobody in the room. (The 2 stores that now have asked set are the 2 of mine that I opened to check, so the merchant count is still 0.)

The trial that wasn't mine

Over the same 4 days the numbers that moved were Pro trials 0 to 1, paid Pro 2 to 2, and listing reviews 0 to 0. One trial, right after shipping trial nudges! You can see how that ends up in a weekly report, can't you?

But I looked at the timestamps. That store completed OAuth at 09:09 UTC on the 24th and started the Pro trial at 10:01 UTC, 52 minutes later. The trial banner only shows to a free merchant with at least 1 active rule, and the review banner needs 7 days of install age, so a brand new install that goes straight to Pro inside an hour was never in a state where any banner could have reached it.

The timing is right and the causation simply isn't there. So the trial goes in the "happened anyway" column, and I'm a bit annoyed at how close I came to filing it under "banners".

And I can't measure clicks anyway

The five upgrade buttons are plain links, href straight to the plan page, so a click never touches my server. There's no tracking code in the app at all, 0 lines of it, and that's deliberate: the privacy page says there are no analytics or advertising trackers embedded in the app, and I'd have to change that public promise before I could count a single click.

Is that worth doing for a click counter? I don't know yet. It's a policy decision rather than an afternoon of work, and I haven't made it.

So the measured effect of the other four banners is not "zero". It's "never measured". Those are different too, and the second one is worse, because you can't even tell whether the thing you built is doing anything.

What I actually learnt

Specifying a banner precisely and getting it in front of a person are separate problems, and I only solved the first one. An in-app message reaches the people who open the app, and a merchant who sets up a rule once and leaves (a perfectly sensible thing to do with a checkout app) will never see anything I put inside it, however good the conditions are.

The other thing is duller but probably more important. Without a mark that gets written when something happens, you can't tell "built" from "reached", and sooner or later you'll take credit for something that happened on its own. The review banner writes a mark. The other four don't. Guess which one I can say anything about?

Anyway, next week the job is getting in front of the 10 merchants who qualify, by some route that isn't inside the app, and deciding whether I'm willing to amend a privacy page for a click counter. The first four banners are still up, still correctly specified, and still unmeasured.

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

The comparison operator that returns true when there is nothing to compare

MinSoo Kim — Fri, 25 Sep 2026 12:02:49 +0000

I've been trying to add a "block the checkout if this rule matches" feature to a Shopify app I run, and I nearly shipped something that would have blocked every single cart in a store. Not some carts. All of them. The bug was one line long and it was already in production, doing something perfectly reasonable, and you'd have to squint to see anything wrong with it. Let's go through it, because I think the shape of it is a lot more common than the specific code, and you probably have one of these somewhere too.

Quick context so you can follow. The app has a small rules engine: 15 kinds of conditions (shipping country, cart total, product, customer tag, whether the address looks like a PO box, that sort of thing), written once in TypeScript and shared between the checkout function that runs as wasm and the rule tester inside the app. The two existing targets use those rules to hide a payment method or to rename a delivery option. The new work was supposed to be small: same condition vocabulary, one more output, "block". Easy, right? I thought so.

Where the function runs

So this is the part I didn't know. Shopify's Cart and Checkout Validation Function is not a checkout-only thing. It runs at 3 points in the buyer's journey: CART_INTERACTION, CHECKOUT_INTERACTION and CHECKOUT_COMPLETION.

The existing two targets only ever ran inside checkout, and the worst they could do to a buyer was hide a payment method a bit early or rename a delivery option. So for as long as that engine has been running, a wrong answer on a cart with no country had never cost anyone a sale. But at the cart stage there is no address yet. Nobody has typed one. And now the wrong answer would stop the sale. Obvious in hindsight? Completely. Did I think of it? I did not.

That is the whole bug, really. The rest is just working out which line it will land on.

The line

Our comparison operators don't fail closed. The not_in branch explicitly returns true when the value is missing. This isn't me guessing after the fact; it's what the code says:

// shared/rules-engine/evaluate.ts
case "not_in":
  return a === undefined || !list.includes(a);

Read that with a merchant's rule in mind: "block if the shipping country is not in [US]". On a cart with no address, a is undefined, so the operator says yes, the country is not in the list, then the rule matches, then the cart gets blocked. And at the cart stage every cart looks like that. From the moment a merchant turns that rule on, nobody will be able to get past the cart. What's the logic in that? There isn't any; it's just what the code does when you ask it to answer a question it wasn't built to answer.

I want to be precise about what actually happened, because "blocked every order" is the kind of sentence that gets repeated. This lived on a branch (feat/validation-rules). It never reached a merchant. The live app can't block anything and still has its 15 conditions. But if I had shipped the branch as it stood, that is what it would have gone on to do.

4 of the 15 conditions read the address: country, province, zip and po_box. The branch adds 4 more address-shaped ones (length, whether there's a street number, contains-string, non-Latin characters), so on the branch it's 8 of 19 that depend on something a cart doesn't have yet.

Why the obvious fixes don't work

So my first thought was the obvious one: make not_in return false when the value is missing. Fail closed, done. Right?

But that operator is not mine to change any more. It's shared with the two targets that are already live, and merchants have built their rules on top of what it does today. Flip the operator and I'd be changing the behaviour of software that merchants have configured and rely on, to fix a feature nobody is using yet. I'm not going to do that.

Second thought: use buyerJourney.step and just skip address rules at CART_INTERACTION. That's what the API is giving you the step for, surely? Surely?

It's not enough. The address can also be empty during checkout, before the buyer has got round to filling in the address form. So a rule can be evaluated at CHECKOUT_INTERACTION with the same missing value and the same wrong true. Filtering by step fixes the cart case and then leaves the checkout case exactly as broken as before.

What I did instead

So the engine now refuses to answer instead of guessing, which I'm pretty happy with. Any rule that needs an address is held until the cart actually has one, and the function decides that by looking at the cart, not at which step it is on.

export const ADDRESS_CONDITION_FIELDS: ConditionField[] = [
  "country", "province", "zip", "po_box",
  // …plus the 4 address-shape conditions (length, street number, contains, non-Latin)
];

export function ruleNeedsAddress(rule: Rule): boolean {
  return rule.conditions.some((c) => ADDRESS_CONDITION_FIELDS.includes(c.field));
}

// Function side. Not buyerJourney.step: does the cart have an address or not.
const addressKnown = (input.cart.deliveryGroups ?? []).some(
  (group) => !!group.deliveryAddress?.countryCode,
);
const { errors } = evaluateValidation(config, ctx, { addressKnown });

The rule tester inside the app doesn't take a default. It works out addressKnown from what the merchant actually typed: if they filled in a country, the rule is evaluated; if they left it blank, it shows "waiting for address" rather than silently matching, which is the same thing the checkout does, just made visible to them.

And there are regression tests pinning both directions now: cart stage with no address lets the cart through, checkout stage with an address blocks it. The original 4 (country, province, zip, po_box) never get evaluated on an address-less cart at all, because ruleNeedsAddress holds the whole rule first. The 4 new address-shape conditions have their own test, and one sentence I made it say out loud, because it's the sentence I got wrong: on a cart with no address, all 4 of them answer "no", including the negative forms (not_in, not_set). 173 tests pass on the branch.

The bit that generalises

The same operator is safe when the worst it can do is hide a payment button, and dangerous when it can stop a sale. Nothing about the operator changed between those two sentences. The thing that changed is how the caller reacts to a true. Is the operator wrong, then? I don't think it is. Is it dangerous? Obviously, in the right place.

So "fail open or fail closed?" isn't a property of the comparison. It's a property of the comparison plus whoever is holding the result. An engine that returns true for "I don't know" has a blast radius decided entirely by its callers, and when you reuse it somewhere new you're not just importing the vocabulary of conditions. You're importing the execution context that vocabulary was written in, and here that context was "the worst a wrong answer can do is hide a button". It wasn't written down anywhere. It was just true, until it wasn't.

I don't have a clever rule for catching this in general, sorry. The honest version is: when a shared function gets a new caller, go and read every branch that handles missing input, one by one, and ask yourself what the new caller will do with each answer. Then write that down. It's boring, but it would have been a lot more expensive to learn after launch.

Anyway, the branch is still a branch, and if you've got a shared rules engine of your own, I'd really go and read its missing-value branches this week. It gets the last checks (typegen, wasm build, a dev store run-through) before it goes anywhere near a real merchant, and now I'm slightly more nervous about the other 11 conditions than I was last week, which is probably the correct amount of nervous.

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

Why CookieMop waits 15 seconds after you close a tab, and why that is the hard part in Manifest V3

MinSoo Kim — Sat, 19 Sep 2026 12:03:56 +0000

CookieMop is a Chrome extension that deletes a site's cookies when you close its last tab, unless the site is on your whitelist. One sentence of product. The interesting engineering is in three words of that sentence: "last", "close", and the delay hiding between them.

Why not delete immediately

Closing a tab by accident is common, and cookies are what keep you logged in. So the extension does not clean on the close event. It schedules a cleanup 15 seconds later (the default; users can change it, and zero means immediate) and only then checks whether the site is still gone. Reopen the tab within the window and the pending cleanup is cancelled. One Playwright test exists for exactly that path: revisiting the site during the delay cancels the cleanup.

That sounds like a setTimeout. In Manifest V3 it cannot be only a setTimeout.

The service worker will not wait for you

In Manifest V3 the background script is a service worker, and Chrome can terminate it whenever it is idle. A timer living inside a worker that gets killed at second 9 of a 15-second wait never fires. The old Manifest V2 answer, a persistent background page, is gone.

The tool Chrome offers instead is chrome.alarms, which survives the worker being unloaded. It has one catch that shaped the whole design: alarms are clamped to a minimum of 30 seconds. A 15-second delay cannot be expressed as an alarm.

So the extension does both. While the worker is alive, a plain timer fires the cleanup on time. In parallel, every pending cleanup is written to storage with its fireAt timestamp, and one alarm is set for the earliest of them, pushed out to at least 30 seconds if needed:

const ALARM_MIN_MS = 30_000; // Chrome clamps MV3 alarms to a 30 s minimum
const earliest = Math.min(...pendings.map((p) => p.fireAt));
chrome.alarms.create(ALARM_NAME, { when: Math.max(earliest, now + ALARM_MIN_MS) });

If the worker lives, the timer wins and the alarm finds nothing to do. If the worker dies, the alarm wakes a fresh worker, which reads the pending list from storage and processes whatever is due. There is a test for that too: kill the service worker, and the alarm still fires the pending cleanup. The cost of the fallback is that a cleanup can land at 30 seconds instead of 15 when Chrome happened to unload the worker. I decided that late is fine and never is not.

"Last tab" means last tab of the site, not the page

The second word. If you have mail.google.com in one tab and docs.google.com in another, closing one must not log you out of the other. So the unit of tracking is not the hostname but the registrable domain, the eTLD+1: mail.google.com becomes google.com, and a.b.example.co.uk becomes example.co.uk.

Doing that properly means knowing which suffixes are "public", and the full Public Suffix List is thousands of entries. CookieMop ships no dependencies and no build step, so it carries a compact table of the common two-part suffixes instead: co.uk, co.kr, com.au, co.jp, 257 entries in total. A hostname ending in one of those needs three labels to be a site; anything else needs two. IP addresses and single-label hosts like localhost are left as they are. It is not the whole list, and I would rather say that here than pretend. It covers the cases people actually log in to.

The same table decides the lists. A whitelist rule on a subdomain survives a cleanup of its parent domain, and a more specific whitelist entry beats a greylist entry. Greylisted sites are the third state: they survive tab close and are cleaned when the browser restarts, in a startup pass that runs before you have opened anything.

The race nobody sees

There is a comment in the background script that I keep because it cost an afternoon. Recording a tab's domain on tabs.onUpdated and taking it back on tabs.onRemoved are both async read-then-write round trips to storage. If a tab is opened and closed fast enough, the "remove" read can overtake the still-pending "record" write, and the extension thinks a site was never open. The fix is a small promise queue that serializes every tab-record read and write, and the reason it is worth writing down is that it never shows up in manual testing. It shows up in a Playwright run that opens and closes tabs faster than a person can.

What "clean" means

By default only cookies are removed. The user can widen the scope to localStorage, or to all site data: IndexedDB, CacheStorage and service worker registrations, through chrome.browsingData. Widening it is a real trade-off, because the same storage that tracks you also holds a half-written draft on some sites, so the narrower default stays.

Everything runs locally. The extension makes no network requests, has no accounts and no analytics, and the repository on GitHub is the code that ships to the store. If you want to check the timer logic yourself, src/background.js is about 430 lines and the alarm fallback is the part worth reading first.

Have you ever lost a login to a tab you closed by mistake, or is 15 seconds too long for the way you browse?

Update, November 7, 2026: CookieMop launched on Product Hunt: https://www.producthunt.com/products/cookiemop

Sources

chrome.alarms API, minimum alarm period in Manifest V3: https://developer.chrome.com/docs/extensions/reference/api/alarms
Extension service worker lifecycle (idle termination): https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle
Public Suffix List, what "registrable domain" means: https://publicsuffix.org/
CookieMop source, the exact code shipped to the Chrome Web Store: https://github.com/thoopring/cookiemop

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

The 10 percent that bought nothing: what a flooring calculator should actually tell you

MinSoo Kim — Wed, 16 Sep 2026 12:02:49 +0000

Wall Math is a set of three small calculators: paint, wallpaper, flooring. The flooring one is the simplest arithmetic on the site and the one that taught me the most about what a calculator owes its user. The whole engine function is nine lines. Here is the part that matters:

const requiredArea = area * (1 + extra / 100);
const boxes = Math.ceil(requiredArea / perBox);
return {
  area, requiredArea, boxes,
  purchasedArea: boxes * perBox,
  excessArea: boxes * perBox - area,
  roundingExtra: boxes * perBox - requiredArea,
};

Area, allowance, divide by the carton, round up. Every flooring calculator on the internet does this. The difference is in what gets returned, and the two extra fields at the bottom are the reason this post exists.

Two kinds of "extra"

When you buy flooring you always take home more than your floor. There are two reasons, and they are not the same kind of thing.

The first is the allowance you chose for cuts, mistakes and a spare plank or two. Ten percent is the number people repeat. It is a decision, and it is yours.

The second is that cartons come in fixed sizes. You cannot buy 3.86 cartons, so you buy 4, and the last carton's remainder lands on your garage floor whether you wanted it or not. That is not a decision. It is arithmetic.

Most calculators add these together and show one number: "you need 4 boxes." The user then reads that as "my 10 percent allowance is included," which is true, and concludes the allowance did something, which is often false.

The worked example that changed the output

A 12-by-15 foot living room is 180 square feet. Take three vinyl plank products from one manufacturer, all cut to the same 7-by-48-inch plank, with cartons of 51.33, 23.64 and 18.91 square feet. Those three figures come from Shaw's own product pages, read on 2026-09-10, and the exact styles are listed in the sources below.

With a 10 percent allowance, the area to cover becomes 198 square feet:

Carton	198 ÷ carton	Buy	Coverage
51.33	3.86	4	205.32
23.64	8.38	9	212.76
18.91	10.47	11	208.01

Now run the same floor with no allowance at all: 180 ÷ 51.33 is 3.51, so still 4 cartons. The other two drop to 8 and 10.

For the largest carton, the 10 percent bought exactly nothing. Four cartons either way. That floor was already going to arrive with 25.32 square feet spare, because you cannot buy three and a half cartons, and 25.32 is more than the 18 square feet that a 10 percent allowance on 180 square feet adds. The rounding had already handed you more than the allowance was ever going to.

On the smallest carton, the same 10 percent is the difference between 10 and 11 cartons. Real money, and also real safety, since dropping it leaves 9.10 square feet spare instead of 28.01.

Same room. Same rule of thumb. It costs a carton in one case and zero in another, and the thing that decides which is a number printed on the side of the box that most people have never looked up.

What the calculator returns now

So the result object separates them. excessArea is everything above the measured floor. roundingExtra is only the part above the area you asked for, the part you could not have avoided at that carton size. The page shows both, and a small chart on the rounding guide draws three bars for a 120 square foot floor: the floor, the floor with 10 percent, and what you actually buy in 23.64 square foot cartons. At 0, 10 and 15 percent allowance that floor is 6 cartons every time. Six, six, six. The allowance slider moves and the answer does not.

I think that is the single most useful thing the page does. Not the count. The count any spreadsheet can produce. The useful part is telling someone, before they drive to the store, that the decision they are agonising over changes nothing for their carton, or that it changes exactly one carton and here is what that carton buys them.

Nobody upstream publishes the 10 percent

We went looking for where the rule comes from. Shaw's vinyl planning and installation page and its flooring overview page, both read on 2026-09-10, state no waste or overage percentage and give no quantity guidance at all. What they do say is to "always work from multiple cartons to achieve a uniform appearance," which is worth knowing if your plan was to open one box at a time and return the rest.

So the calculator labels the allowance as the user's input, not a recommendation. The assumption string in the result says so in plain words, and the page repeats it. Which number did you assume was a rule the last time you bought flooring?

Checking arithmetic you publish

Every worked number in the guides, including the 0 to 15 percent allowance table, was computed by hand and matched against the engine's regression tests before the pages went live. That is slow, and it is the only way I know to publish a table of numbers under my own name without flinching. The whole formula fits on one line: floor area × (1 + allowance) ÷ square feet per carton, rounded up. The work is in saying which part of the answer was your choice.

The calculator is here: https://www.wallmath.com/flooring-calculator/

Sources

Shaw Prime Plank, style 0616V: 51.33 sq ft per carton, 7 in × 48 in planks: https://shawfloors.com/en-us/vinyl/prime-plank-greyed-oak-7-/0616v-00532
Shaw Distinction Plus, style 2045V: 23.64 sq ft per carton: https://shawfloors.com/en-us/vinyl/distinction-plus-barrel-oak-7-/2045v-07066
Shaw Paladin Plus, style 0278V: 18.91 sq ft per carton: https://shawfloors.com/en-us/vinyl/paladin-plus-fresh-pine-7-/0278v-05052
Shaw vinyl planning and installation page, no waste percentage stated (read 2026-09-10): https://shawfloors.com/en-us/plan-and-install/vinyl
Wall Math rounding guide (allowance vs whole-box rounding): https://www.wallmath.com/flooring-boxes/

This post was drafted with AI help. The numbers and facts come from my own logs and repo.

The checkout never calls our server: how HideKit's rules run inside Shopify

MinSoo Kim — Mon, 14 Sep 2026 12:03:29 +0000

HideKit is a small Shopify app. A merchant writes rules like "hide cash on delivery for orders under ₩100,000 shipped to Korea" or "rename Standard Shipping to Ground for US addresses", and the checkout follows them. If ten thousand merchants installed it tomorrow, our server would not get one extra request at checkout time. That is the part I want to explain, because it decided almost everything else about how the app is built.

Where the rules live

The rules do not live in our database. They live in one JSON document in a Shopify metafield attached to the merchant's payment customization, under the namespace $app:payment-rules with the key function-configuration. A second customization holds the delivery rules. Our admin app writes to that metafield, and nothing else of ours is involved after that.

At checkout, Shopify runs a Function. Ours targets cart.payment-methods.transform.run, and a sibling targets cart.delivery-options.transform.run. Shopify hands the function an input it asked for in a GraphQL query: the cart total and currency, discount applications, the buyer's company if it is a B2B checkout, the customer's amount spent, order count and tags, the delivery address down to province and zip, each line's weight and collection membership, and the checkout language. The function reads the metafield, evaluates the rules against that input, and returns a list of operations: hide this method, rename that one, move this one to a different position. Three operation types, one metafield read, zero network calls. That is the whole runtime. If our servers are down, the checkout does not notice.

The function is compiled to WebAssembly and executed by Shopify, so the engine had to be plain TypeScript with no I/O. That constraint turned out to be a gift.

One engine, two callers

Because the engine is a pure module, shared/rules-engine, the admin app can import the same code. HideKit has a page called the Rule Tester where a merchant types in a cart: country, total, products, tags, and a list of payment methods (the default is three: cash on delivery, credit card, bank deposit). The page runs the merchant's saved rules through the same evaluateRules function the checkout uses and shows which rules fire and what each method would look like. No test orders, no fake customers, and no chance that the tester and the checkout disagree, because there is only one implementation.

"Why isn't it hidden?" is the support question every app in this category gets. The tester exists so the merchant can answer it themselves before a customer ever sees the checkout. Which method do your customers keep picking that you wish they wouldn't? That is usually the first rule a merchant writes.

Testing a thing you cannot step through

You cannot attach a debugger to a function running inside Shopify's checkout. So the tests run the compiled wasm against fixtures. There were 89 tests in the suite at the last count I wrote down, including an 18-case condition matrix run through the wasm build and boundary fixtures such as a rule at 20 with carts at 20 and 19.99, because "greater than or equal" is exactly the kind of thing that gets flipped in a refactor.

The end-to-end check was done by hand on a development store with a rule that reads "country is KR AND total is at least ₩100,000": a ₩58,000 cart showed cash on delivery, a ₩116,000 cart hid it. Boring, and the only proof that matters.

The incident that became a smoke test

Cleaning up a development preview once removed the payment customization that owned the metafield. The rules were still visible in the merchant's admin, pointing at an owner that no longer existed. The fix was to recreate the customization with the released function's ID, and doing it through the app's own UI turned the fix into a full pass of the create path: UI to server to the customization-create mutation to metafieldsSet. It is the most useful bug we have had, because it forced the exact flow a new merchant goes through.

What the architecture cannot do

Living inside Shopify means living with Shopify's limits, and we list them in the app instead of discovering them with a merchant. On non-Plus stores, checkout does not allow hiding the Shopify Payments gateway itself; only individual methods like cash on delivery or manual payments can be hidden. There is also a known checkout bug where a customer who selected a method that then becomes hidden can get stuck, so onboarding flags it up front. Two limits, both written on the listing, because a refund request is a worse place to learn about them.

I would build it this way again. The rules being the merchant's data, in their store, evaluated by the platform, is not only a nice property for uptime. It means uninstalling the app leaves nothing behind in the theme, and it means the thing the merchant tests is the thing that runs.

If you want to see the tester, the listing is here: https://apps.shopify.com/hidekit.

Sources

Payment customization function target: https://shopify.dev/docs/api/functions/reference/payment-customization
Delivery customization function target: https://shopify.dev/docs/api/functions/reference/delivery-customization
Shopify Functions overview (WebAssembly execution, input queries): https://shopify.dev/docs/apps/build/functions
HideKit listing, including the platform limits section: https://apps.shopify.com/hidekit

This post was drafted with AI help. The numbers and facts come from my own logs and repo.