DEV Community

Sell one API call to an agent

DAMILARE OLALEYE — Fri, 13 Nov 2026 13:20:19 +0000

If an agent needs to buy access to an API, payment and execution need to be tracked separately. This tutorial walks through a test purchase, checks settlement, and reserves one authorized lookup.

Quote a test purchase, confirm payment, and reserve one authorized execution.

What you will build

A buyer agent purchases one fixed-price lookup and the seller delivers it after payment settles and the seller's own policy permits it. The examples use TypeScript and Test credentials. Your application supplies durable storage, its authorization policy, and the actual lookup.

You need separate seller and buyer workspaces, a seller test payment account, a 100 USD cents API-call resource, and Test keys with charge:budget, charge:buy, and charge:fulfill for their respective roles. Follow seller and buyer setup first. Keep all keys on your servers and use the same environment throughout.

Install @chitmark/sdk in a TypeScript project. Set CHITMARK_BUYER_BUDGET_KEY, CHITMARK_BUYER_KEY, and CHITMARK_SELLER_FULFILL_KEY to the corresponding Test keys. Set CHITMARK_SELLER_ID, CHITMARK_BUYER_ID, and CHITMARK_RESOURCE_ID to the IDs from setup, and CHITMARK_OPERATION_ID to a new, durable ID for this lookup. CHITMARK_API_BASE_URL is optional and defaults to the production API endpoint. Run the buyer example in your TypeScript runtime; the later snippets are separate steps using the saved state.

Configure a seller and quote a lookup

In the seller workspace, select Test and complete test payment setup. Under Resources, create an enabled API-call resource priced at 100 USD cents for one call. Save its ID and both workspace IDs. Test checkout uses the seller's test payment account.

Use the same server-side values throughout the purchase. Save the lookup inputs, operation ID and digest with the purchase before handing off to checkout. Keep the intent and each mutation's idempotency key stable across retries. A retry uses the same key and exact payload. The examples below use TypeScript. In Python, pass the same request dictionaries to client.charge(...) and read the same response fields.

Set the ceiling and accept

import { createHash } from "node:crypto";
import { Chitmark } from "@chitmark/sdk";

function api(name: string) {
  const apiKey = process.env[name];
  if (!apiKey?.startsWith("ck_test_")) throw new Error(name + " requires a Test key");
  return new Chitmark({ apiKey, baseUrl: process.env.CHITMARK_API_BASE_URL });
}
const owner = api("CHITMARK_BUYER_BUDGET_KEY"); // charge:budget
const buyer = api("CHITMARK_BUYER_KEY"); // charge:buy

const sellerTenantId = process.env.CHITMARK_SELLER_ID!;
const buyerTenantId = process.env.CHITMARK_BUYER_ID!;
const resourceId = process.env.CHITMARK_RESOURCE_ID!;
// Assign and persist this ID in your application before the first request.
const operationId = process.env.CHITMARK_OPERATION_ID!;
const lookup = "acme";
const operationDigest = createHash("sha256")
  .update(
    JSON.stringify([operationId, sellerTenantId, buyerTenantId, resourceId, lookup]),
  )
  .digest("hex");

await owner.charge({
  operation: "budget",
  sellerTenantId,
  buyerTenantId,
  limit: 500,
  idempotencyKey: "budget:" + operationId,
});

const quoted = await buyer.charge({
  operation: "quote",
  sellerTenantId,
  resourceId,
  quantity: 1,
  operationDigest,
  idempotencyKey: "quote:" + operationId,
});
if (!("purchase" in quoted)) throw new Error("Quote unavailable");
const { purchaseId, quote } = quoted.purchase;
if (quote.amount !== 100 || quote.currency !== "usd") throw new Error("Unexpected terms");

const accepted = await buyer.charge({
  operation: "accept",
  sellerTenantId,
  purchaseId,
  quoteVersion: quote.version,
  maxAmount: quote.amount,
  currency: quote.currency,
  idempotencyKey: "accept:" + purchaseId,
});
if (!("purchase" in accepted)) throw new Error("Purchase unavailable");
// Save the purchase ID and digest in your application.
console.log({ purchaseId, operationDigest, next: accepted.next });
if (accepted.next === "pay" && accepted.purchase.checkoutUrl) {
  // Test script only. In your app, pass the URL to the authorized payer.
  console.log(accepted.purchase.checkoutUrl);
}

Complete test checkout and check capture

Open the returned purchase.checkoutUrl for the authorized test payer and complete checkout. If next is wait, read status for the same purchase instead of starting another. Use status to recover the current checkout URL or payment state after an interruption.

After checkout, run the status request with the same buyer key and purchase ID. Keep waiting while payment is pending or authorized. Continue only when payment.state is settled. A checkout redirect or a Trust Decisions allow carries no payment authorization.

Check payment

const status = await buyer.charge({ operation: "status", sellerTenantId, purchaseId });
if (!("purchase" in status)) throw new Error("Purchase unavailable");
if (status.next === "pay" && status.purchase.checkoutUrl) {
  console.log(status.purchase.checkoutUrl); // Test script only
}
if (status.purchase.payment.state !== "settled") {
  throw new Error("Hold fulfillment until payment is settled");
}

Authorize, reserve, and fulfill one lookup

Run fulfillment on the seller backend using CHITMARK_SELLER_FULFILL_KEY. Load the saved purchase and operation digest. Check that the authenticated buyer may access this lookup under your own policy. If a Trust Decisions verdict justified this specific permission, include its stored eventId when you record permission.

Persist a unique execution ID before requesting the reservation. The example uses an application-provided deliverOnce function for the actual lookup. Implement it so the output or business effect and the execution ID commit together. Reuse the ID on retry. If you lose the reserve response, read the current purchase and reconcile instead of executing without a fresh granted lease.

Reserve and report usage

const seller = api("CHITMARK_SELLER_FULFILL_KEY"); // charge:fulfill
// Application values loaded from durable state after checking local policy.
if (!localPermission) throw new Error("Lookup not authorized");
await seller.charge({
  operation: "permission",
  sellerTenantId,
  purchaseId,
  allowed: true,
  idempotencyKey: "permission:" + executionId,
});

const reserved = await seller.charge({
  operation: "reserve",
  sellerTenantId,
  purchaseId,
  executionId,
  operationDigest,
  units: 1,
  idempotencyKey: "reserve:" + executionId,
});
if (
  !("purchase" in reserved) ||
  reserved.purchase.payment.state !== "settled" ||
  !reserved.purchase.permission.allowed ||
  !reserved.reservation?.granted ||
  reserved.reservation.executionId !== executionId ||
  Date.now() >= reserved.reservation.leaseUntil
) {
  throw new Error("Hold delivery");
}

await deliverOnce({
  purchaseId,
  executionId,
  lookup,
  leaseUntil: reserved.reservation.leaseUntil,
});
await seller.charge({
  operation: "usage",
  sellerTenantId,
  purchaseId,
  executionId,
  sequence: 1,
  usedUnits: 1,
  result: "delivered",
  idempotencyKey: "usage:" + executionId + ":1",
});

Verify and recover

Read the purchase with the buyer key or find it under Agent Paid Access → Purchases in the seller workspace. Confirm the execution is delivered and has one used unit. Try fulfilling before settlement and with local permission denied: both must hold delivery.

Persist the operation ID, inputs, digest, purchase ID, and execution ID before their respective steps. Retry a lost request with the same idempotency key and exact payload. If the reservation response is lost, inspect and reconcile the purchase instead of delivering without a fresh granted lease. If delivery is uncertain, keep the units reserved and reconcile before retrying. If usage reporting fails after delivery, retry the same usage payload.

The fulfillment example is a server-side integration fragment: implement localPermission and deliverOnce in your application. deliverOnce must durably deduplicate by execution ID and enforce the lease at the execution boundary. Refunds and disputes can change payment state after settlement. See the charge reference for operations and scopes, and the quickstart for live setup.

Read the full guide on Chitmark.

Future directions of travel

Dan Walsh — Fri, 13 Nov 2026 13:18:54 +0000

I already put this in the log, but whatever. Free will n all that, I'm double posting.

Been thinking about the future of SWE and agentic use in general (shocker, who working in SW hasn't?)

In my eyes: verification and governance.

My prediction on SWE directions: verification engineering becoming a massive discipline/the new standard for software engineering at large.

We're no longer hand crafting pieces of curated, artisanal code to try and solve problems.

Aside: people sometimes seem to forget solving problems was the point of the job in the end - writing code in and of itself was not the full job, but many people seem to have made it their personality or their measure of value/impact as an engineer, and are now struggling with their identity as a result, but that's a different thread.

I understand the tension here. Hand writing code gave many of us the level of scrutiny that allowed for an ongoing understanding and verification in terms of the code produced, but as the be all and end all of a given engineer's identity, it's now far too limiting.

We're now at the factory's production line, and our job is to assess which of the different experiments and approaches output by an agentic session best address a given problem, which is most extensible and/or maintainable for the future and its problems to address, and to provide a level of confidence and rigour to how we arrived at that decision.

How do we do that? With the necessary guardrails, assessments, and verification practices in place.

Zoom out, same problem appears at a bigger scale. Verification is governance at the scale of a PR; governance is verification at the scale of an organisation.

Governance.

Not the sexiest option by a mile, but it feels like the right route, because we're slowly (or quickly depending on your personal perceptions and p(doom)) offloading our cognitive capabilities to a subscription service.

Intelligence and aptitude on demand, where we need to pay a given value each month to be in with a fighting chance in the ongoing arms race of individual capability.

I'm convinced that, of all the AI safety risks we need to guard against, gradual disempowerment and over-reliance are far too easily overlooked in favour of misuse, for example. Misuse / CBRN applications are obviously terrifying, and real problems, but the insidiousness of disempowerment is the killer to me.

In X industry, Y organisation is so much further ahead than us! We need to use AI to catch up. We don't have time to spend dwelling on these decisions and problems - DecisionBot 9000, what's your suggestion here? Ok great, implement that.

Fast forward Z months/weeks/days later - I don't understand any of this. Where are we? Let's ask AI - it's best informed and capable to consume the information we have here, get its assessment and then we'll go with its recommendations.

At what point do we recognise the problem that's developed? How do we even begin to pull ourselves out of that hole? Do we even recognise we're boiling along with the other frogs?

We need governance in place to try and offset these situations at the earliest possible points. In practice: named human(s) owning each significant decision, with the ability to explain it without asking a model, and recording why a given recommendation was accepted, not just that it was.

I don't wanna be a dang frog.

I cut my CI wait from 25 minutes to about 12 and checked that no test was dropped

Miguel Shinyenyi — Fri, 13 Nov 2026 13:18:16 +0000

The wait

umwayi-os is a Python command line with a large test suite. It has more than 2,000 tests. They run on every pull request, on Python 3.10, 3.11, 3.12 and 3.13. The core uses only the standard library, so the tests start real child processes in temporary folders. That makes them thorough and slow. The code is public: https://github.com/Miguel-Shinyenyi/umwayi-os

On Nov 12 I measured one job on one pull request: 24.9 minutes. Each job ran the whole suite, and one push could start two runs of four jobs each. The tests alone took about 1,810 seconds on Python 3.11.

I build this project with several AI builders working in parallel. Each pull request is reviewed and then merged. A 25 minute wait on each push slows every round of review.

Before: one push
-------------------------
push
 +- run 1: 4 jobs
 +- run 2: 4 jobs
each job: all tests
each job: about 25 min
-------------------------

Step 1: stop running the same thing twice

The first change was small (pull request 59). CI ran on pull requests only, and a newer push cancelled the older run. One push now means one run of four jobs. I also cached the npm download. That saved little: the whole Node step was 0.4 minutes of a 24.9 minute job. I cached it anyway, and I wrote the number in the pull request.

This change cut the number of runs. It did not shorten one run.

Step 2: do not run what a change cannot affect

Most pull requests do not touch most of the code. A change to a documentation page cannot break a test that never reads that page. But "cannot" has to be proven, not assumed.

I wrote a map. For every test file, the map lists which paths outside its own area the test reads. A script scans the test files and fails when a test reads a path the map does not list. The map is data in tools/ci_map.json, and tests/test_ci_map.py keeps it true.

The scan corrected my own guesses. I had estimated that 27 test files touch the adapters folder. The scan found 43. I had estimated 10 touch the .kiro folder. Only 4 read it. The rest only mention it in a path inside a temporary folder. Only 23 of 115 test files read anything outside tests/ and umwayi/.

A second script, the plan, reads the changed paths of a pull request and decides which jobs run. Its rules are strict:

changed path
   |
   v
anything unusual?
   unknown path
   odd path
   change under .github/ or tools/
   push to main
   |
   +-- yes: run everything
   |
   v
no: use the longest matching
route in the map
   |
   v
whole suite, some test files,
or none

The default is to run everything. The filter only narrows the run when it can prove the narrowing is safe. A push to main always runs all four Python versions, so a wrong filter is caught within one merge.

Step 3: split the rest into three shards

Each test job still ran the whole suite. I split the test files into three shards per Python version. I measured the seconds of every test file and balanced the three lists by those seconds. The lists live in tools/ci_shards.json, and one command rewrites them from the measurements.

one job   ##############################
shard 1   ##########
shard 2   ##########
shard 3   ##########
          each # is about 60 seconds

One job took 1,810 seconds of test time. Each shard takes about 603 seconds. The three shards run at the same time.

Step 4: prove that nothing was dropped

Splitting creates a new way to fail. A shard can skip a test file and still report green. If a plan leaves out a job, a skipped job looks like a pass. I wanted neither.

So I added one check that always runs, last, named result. It is the only check a branch rule needs to require. It fails when any of these is true:

the plan job failed
a planned job was skipped
a planned job was cancelled
a shard wrote no report
a shard reports a test that did
  not start
two shards disagree about which
  tests exist
a test file is in no shard
the tests that ran are not all the
  tests found in the selected files

I tested the check with planted faults. One test makes a shard drop a test that never starts. Another adds a test file to no shard. Both must turn result red, and both do. The summary of a green run also lists what it did not run, with the reason. What the plan left out runs on main after the merge.

I did not trust the check until I saw it fail on purpose.

final result
   |
   v
every planned job passed?
every shard reported?
every test found also ran?
   |
   +-- no to any: red
   |
   v
yes to all: green, with a list of
anything not run and why

Step 5: the same filter on a laptop

The builders did not need CI to tell them what to run. tools/affected_tests.py reads what differs from main and asks the same function as the CI plan, with the same map. A test proves it prints the same plan as CI for the same changed files. While building, a builder runs only the affected tests. The whole suite runs only when the tool prints FULL SUITE. GitHub CI stays the record.

What I measured after

I read the run times from the Actions page for pull requests 73 to 89.

A documentation only pull request: 1 minute 30 seconds for its first run.
Pull requests that run the whole Python suite: 11 minutes 22 seconds to 12 minutes 4 seconds in the typical case.
Heavier runs: 13 to 22 minutes, on pull requests 73, 80, 83, 84, 85 and 88. I checked these on GitHub. The extra time is waiting: when several runs overlap, their jobs wait for a free runner before they start.

Before, one job took 24.9 minutes. A typical full run now takes about 12. That is the 25 to 12 in the title.

What I do not know yet

I did not measure total runner minutes. Three shards per version repeat setup work, so the total may be the same or higher. The wait fell. The cost may not have.
I cannot run the workflow file on my machine. A test pins its text, and the real run on GitHub is the record.
The affected-only run can miss a test that reads a path built from data, or a path a child process reads from its working directory. The scanner cannot see those. A change inside umwayi/ runs the whole Python suite for that reason.
The four old check names no longer exist. A branch rule that requires them waits forever. I have to change that rule by hand, and I have not yet.

What I took from it

Measure before you guess. My counts of which tests touch which folders were wrong by a wide margin, and the scan fixed them.
A filter that cannot prove it is safe should run everything.
Splitting a suite adds a failure you cannot see: a shard that drops a test and still reports green. Add a check that compares the tests found with the tests run.
A skipped job is not a pass. Say what was skipped and why.
Test your check by breaking things on purpose, and watch it go red.
Time spent waiting for a runner is not time spent running. With several builders pushing at once, runs overlap and queue, so a typical run time understates the wait.

Originally published on my site.

A Shopify CSV checker with line-level reports and an n8n import gate

didyouseethis212-sys — Fri, 13 Nov 2026 13:17:57 +0000

Disclosure: I maintain Catalog Import Guard, including its paid API. This article was prepared with AI assistance, and the sample results and workflow execution were checked before publication.

A product CSV can be valid CSV and still contain an accidental duplicate variant, a price field with a currency symbol, or an empty field that changes an existing value during an overwrite. I built a small checker around that pre-import step.

Try the browser checker — no account, API key or Shopify installation is required. The CSV is checked on your device.

An example you can reproduce

Load the built-in example, or paste this CSV and choose Update products:

URL handle,Title,Option1 name,Option1 value,Price,Vendor
linen-shirt,Linen Shirt,Size,S,49.00,
linen-shirt,,,S,$39.00,

The report contains two errors and one warning:

Physical line	Finding	Why it needs review
2	Blank Vendor overwrite warning	With overwrite enabled, an empty vendor can clear an existing value.
3	Duplicate variant	Size S already appears within the same product handle.
3	Price format	The price field expects a number without a currency symbol.

The checker reports physical line numbers, including files with quoted multiline cells. It does not guess what a price should be or change a store.

Using the same check in n8n

For a recurring supplier-file handoff, the public workflow and setup guide are on GitHub.

The workflow runs two synthetic cases, sends CSV text to the API, validates the response shape, produces a downloadable CSV issue report for each item, and routes blocking findings separately from results ready for manual review.

An HTTP 200 response alone does not mean the catalog passed. Errors, failed checks or a truncated report go to the blocked branch. A passing, untruncated result goes to the review branch. Both branches are connected; neither imports products or sends messages.

Import and execution were verified in local n8n 2.46.6 using the actual Worker handler through a localhost fixture and synthetic authentication. Both branches and the binary report filenames were checked. I have not tested this in n8n Cloud or through a real Shopify import.

Costs, data and limits

The browser checker remains free and local. The n8n workflow requires your own RapidAPI key and sends CSV text to the API. Remove customer information and credentials first.

The current API plans include BASIC at $0 for 100 requests/month and PRO at $5 for 1,000 requests/month, subject to platform terms, request limits and bandwidth fees. The two-case tutorial makes two requests per run. Your n8n hosting can have separate costs.

The browser accepts UTF-8 CSV text up to 256 KiB and 5,000 rows. API requests have a 256 KiB encoded JSON limit, so JSON escaping also counts. Checks cover selected product CSV fields; a passing result does not guarantee Shopify accepts an import. Review overwrite warnings and Shopify's own import preview before importing.

If you handle supplier CSVs, which errors take the most manual checking? A synthetic row and the relevant column names are enough to discuss a case; please do not post private catalog or customer data.

Recognize an agent in your API

DAMILARE OLALEYE — Fri, 13 Nov 2026 13:17:52 +0000

When an agent calls your API, knowing whether it has been seen before can help your application provide continuity. This tutorial shows how to resolve an agent proof and handle the result in a server-side endpoint.

Resolve an incoming agent proof and handle recognized, unknown, and unavailable identity evidence.

What you will build

Add a server-side endpoint that resolves an incoming agent proof and returns a different response for recognized agents, unknown visitors, and unavailable identity evidence. Attribution provides evidence for your application's access policy; recognition alone does not authorize an action.

You need Node.js or Python, a Chitmark workspace with Attribution enabled, a Test key with attribution:read, and your site's exact public HTTPS origin. To test recognition, you also need an enrolled agent and a fresh proof for that site. The two-website example walks through enrollment and signing.

Install the SDK and configure your site

Use SDK version 0.9.0 or later for network proofs. Create a Test API key with attribution:read in your site's workspace. Set CHITMARK_API_KEY on the server and set CHITMARK_SITE to your exact public HTTPS origin, for example https://app.example.com without a trailing slash. The SDK uses https://api.chitmark.com by default.

Give the visiting agent your workspace ID, recipient key record ID, origin, environment, purpose and data mode. Keep the bearer credential on your server. The agent sends a fresh Chitmark-Agent-Proof header for those values. The defaults are identity_attribution and hashed.

Node.js

npm install @chitmark/sdk

Python

python -m pip install chitmark flask

Add an endpoint

Set CHITMARK_API_KEY to your Test read key and CHITMARK_SITE to your public HTTPS origin, such as https://app.example.com. Save the Node.js example as attribution.mjs or the Python example as attribution.py. The server listens on 127.0.0.1:3000. Its configured site is used for resolution, not a client-supplied Host header.

Run node attribution.mjs or python attribution.py. Then run curl http://127.0.0.1:3000/agent-task without a proof. You should see Unknown visitor.

Node.js

import { createServer } from "node:http";
import { Chitmark, ChitmarkError } from "@chitmark/sdk";

const site = process.env.CHITMARK_SITE;
const apiKey = process.env.CHITMARK_API_KEY;
if (!site || !apiKey) throw new Error("Configure CHITMARK_SITE and CHITMARK_API_KEY");
const piiMode = process.env.CHITMARK_ATTRIBUTION_PII_MODE === "raw" ? "raw" : "hashed";
const chitmark = new Chitmark({ apiKey, piiMode });

createServer(async (incoming, response) => {
  if (incoming.url !== "/agent-task") {
    response.writeHead(404).end();
    return;
  }
  response.setHeader("Cache-Control", "no-store");
  try {
    const result = await chitmark.attribution.resolve({
      site,
      request: {
        url: incoming.url ?? "/",
        headers: incoming.headers,
      },
    });

    if (process.env.CHITMARK_FIXTURE_LOG === "1") {
      console.log(result.identity.recognized);
      console.log(result.principal.email);
    }

    if (!result.identity.recognized) {
      response.end("Unknown visitor");
      return;
    }
    if (result.principal.status === "previously_verified") {
      const email = result.principal.email;
      response.end(
        email === null
          ? "Recognized agent; verified principal; email unavailable"
          : "Recognized agent; verified principal; email authorized",
      );
      return;
    }
    response.end("Recognized agent; principal unavailable");
  } catch (error) {
    if (!(error instanceof ChitmarkError)) throw error;
    response.writeHead(503).end("Identity evidence unavailable");
  }
}).listen(3000, "127.0.0.1");

Python

import os

from flask import Flask, request
from chitmark import Chitmark, ChitmarkError

app = Flask(__name__)
site = os.environ["CHITMARK_SITE"]
pii_mode = "raw" if os.getenv("CHITMARK_ATTRIBUTION_PII_MODE") == "raw" else "hashed"
client = Chitmark(api_key=os.environ["CHITMARK_API_KEY"], pii_mode=pii_mode)

@app.get("/agent-task")
def agent_task():
    headers = {"Cache-Control": "no-store"}
    try:
        result = client.attribution.resolve(request=request, site=site)
    except ChitmarkError:
        return "Identity evidence unavailable", 503, headers

    identity = result["identity"]
    principal = result["principal"]
    if not identity["recognized"]:
        return "Unknown visitor", 200, headers
    if principal["status"] == "previously_verified":
        email = principal["email"]
        message = (
            "Recognized agent; verified principal; email unavailable"
            if email is None
            else "Recognized agent; verified principal; email authorized"
        )
        return message, 200, headers
    return "Recognized agent; principal unavailable", 200, headers

if __name__ == "__main__":
    app.run(port=3000)

Exercise each result

Test	Expected behavior
No proof and no separate session evidence	The endpoint returns `Unknown visitor`.
Fresh proof for this site from an enrolled agent	The agent is recognized. Principal details can still be withheld.
Recognized agent with a disclosure grant	The principal can be previously verified; email can still be unavailable.
Attribution service unavailable	The endpoint returns 503; do not treat the failure as recognition.

Use the two-website example to generate a fresh proof for the exact recipient, environment, purpose, and data mode, then include it in the Chitmark-Agent-Proof header. Repeat with a proof for another site or a revoked binding and check the unknown path. Test failures by temporarily making the service unreachable in a test environment.

Use the site's scoped identity.subject_id for continuity, and apply your own authorization before protected work. Keep API keys, proof headers, and personal data out of logs. Email disclosure requires the appropriate grant, consent, plan, scope, and raw mode; see the quickstart.

Read the full guide on Chitmark.

What to check before buying a ready-made admin panel template

Mehedi Mansur Rafi — Fri, 13 Nov 2026 13:17:19 +0000

Part 1 of Before You Buy Code.

I build admin panels for clinic and small business sites, and I have bought templates to save time. Two of them cost me more time than they saved. The screenshots were fine. The faults sat in parts a screenshot cannot show: a login with no roles behind it, a package with half the pages from the sales page, and setup docs that stopped before the first error.

Now I run the same checks on every Laravel admin panel template before I pay. Each check has a good sign and a red flag, and most take minutes with a demo or a file list. At the end I run the list on AdminForge, the kit I sell.

Check 1: log in, then log in as someone with fewer rights

Open the demo and sign in as admin. Create a second account with a staff role, sign in as that account, and open a settings page by typing its address.

Good sign: the second account sees fewer pages, and the server refuses the admin pages at the typed address.

Red flag: the sales page lists roles, and the demo has one login that opens everything. A menu that hides links is decoration. When the second account can open the user list by address, permissions are missing, and adding them later means touching every page.

Check 2: count the Blade files and open the layout

Ask for the file list, or open the package and count the files in resources/views. The count tells you how much of the panel is real pages. A sales page can show thirty screens that turn out to be ten views in different colors.

Then open the main layout file. Good sign: the sidebar and the top bar sit in the layout once, and each page fills the middle. Red flag: the menu code is pasted into every view. With a pasted menu, one menu change becomes the same edit repeated across twenty files.

Check 3: look for migrations and run them

Open database/migrations. Good sign: files exist for the tables the panel needs, users, roles, settings, and the rest, and php artisan migrate builds them on a throwaway database with no errors.

Red flag: the setup guide starts with "import this SQL file", and no migrations ship. A dump ties your project to the seller's test data. A second mismatch: HTML screens only, with no migrations, sold under copy that calls the package a complete admin system. An HTML kit is fair when the listing sells it as one.

Check 4: seed the database and look at full pages

Check database/seeders, then run php artisan db:seed. Good sign: seeding creates a demo admin account, some users, and sample rows in the main tables, and the docs print the demo login.

Red flag: no seeders ship at all. Every list page opens empty, so you cannot tell an empty table from a broken query, and the first day goes to typing test rows by hand.

Check 5: read the documentation before the code

Read the install guide from the top. Good sign: it lists the server requirements, the install commands in order, a page list, and the first changes every buyer makes, adding a menu item, changing the logo or colors. The screenshots in the docs show the version the package installs.

Red flag: the whole documentation is one short readme that ends at the install command. When setup fails at step three, a thin readme leaves you searching the web for an answer the seller should have written down.

Check 6: read composer.json and match it against your server

Open composer.json and read the require section. It names the PHP version and the laravel/framework version the kit was built for. Laravel 11 and 12 both need PHP 8.2 or above. Run php -v on your server, or read the version in your hosting panel, and compare before you pay.

Good sign: the listing states the versions and composer.json agrees. Red flag: the listing says the kit works with the latest Laravel, and composer.json pins an old major version. Treat a missing composer.json the same way when the kit calls itself a Laravel package.

Once the panel is in your app, the app still has to go online. My earlier post on putting a Laravel website online covers the server side: https://dev.to/mehedirafi/how-to-put-a-laravel-website-online-step-by-step-3oif

Check 7: find the licence and answer three questions from it

Find the licence file in the package, or the terms on the listing, and answer three questions from the text. Can you use the template in a client project? How many projects does one purchase cover? Can you charge the client for the finished site?

Good sign: the licence answers all three in plain lines. Red flag: no licence file exists anywhere, or the terms allow one personal project while the sales page shows the kit inside client work. Buyers skip this check more than any other, and it is the one that can turn a paid template into an argument with your own client.

Check 8: check the update history and the questions under the listing

Find the changelog or the release dates. Good sign: a release within the last few months that fixes bugs or follows a Laravel release, and an update window stated in the price.

Then read the public questions under the listing. Sellers who support their work answer in the open. Red flag: the last update landed two Laravel versions ago, and the newest questions sit unanswered with bug reports in them.

A 15 minute test when a live demo exists

Work through the demo in this order. Sign in. Open every item in the menu and note any page that errors. Save one setting and check that it stays saved. Open an invoice page and print it. Create the low role account from Check 1 and revisit one admin page.

When no demo exists, read the file list against the page list twice, then send the seller the two questions the listing leaves open. The reply tells you a lot about the support from Check 8 before money moves.

The same list, run on my own kit

AdminForge is my own product, so read this part as a seller showing his work. The listing states 34 Blade files and names the main pages: login, roles, settings, and invoice pages. Check 1 and Check 2 tell you to open those pages and count those files against the claim.

AdminForge is a UI kit, and you connect the Blade views to your own app. That puts the database checks from this list on your side: your migrations, your seeders, your data.

A score sheet you can reuse

Copy these lines into a note and mark each pass or fail:

A low role account is blocked from admin pages by the server
Blade file count matches the page list on the sales page
Migrations ship with the package and run clean on a test database
Seeders fill the main tables, and the docs print the demo login
Documentation covers install, the page list, and first changes
composer.json versions match the listing and your server
The licence allows client work and states the project count
A recent release exists, and listing questions get answers

AdminForge is my own Blade admin kit. It has 34 Blade files, with login, roles, settings, and invoice pages. It is a UI kit, so you connect it to your own app. The listing says exactly what is inside: https://mehedirafi.gumroad.com/l/adminforge

I am Mehedi Mansur Rafi, a freelance Laravel developer (B.Sc. in Computer Science & Engineering). I build hospital, clinic, and small business websites. CarePoint Admin is my admin kit for clinic work: https://mehedirafi.gumroad.com/l/carepoint-admin. My full store is at https://mehedirafi.gumroad.com/ and my site is https://mehedimansurrafi.online

AgentedSEO Review: A WordPress SEO Plugin Your AI Agent Can Run

SoloAgentFlow — Fri, 13 Nov 2026 13:17:16 +0000

AI agents can already write and publish WordPress posts. The weak spot has been SEO: once an agent starts editing titles and meta descriptions behind the scenes, you lose track of what it changed and why. AgentedSEO is a plugin built to close that gap. Here is what it does, what the launch deal costs, and three realistic ways to turn it into paid work.

TL;DR

AgentedSEO gives AI agents their own WordPress login limited to SEO-only rights.
Every agent change shows before and after, needs approval on live pages, and can be undone.
The founder reports a first $129 sale two hours after posting the launch.
Launch lifetime pricing runs from $49 to $199 and, per the founder, closes December 1.

Why this plugin exists

The founder runs a WordPress agency in Pune and builds plugins on the side. The idea came from the founder's own site, where an AI agent already writes and publishes the posts. For SEO, though, the agent still needed a second plugin, and when it edited meta data through the WordPress REST API, the founder says there was no way to see what it had changed.

That is a familiar problem for anyone automating content. An agent that silently rewrites a live page's SEO fields is a liability, not a time saver. So the founder built an SEO plugin where the agent is treated as a first-class user instead of a hidden script.

How AgentedSEO works

The setup is designed around trust and visibility. Here is what the founder describes:

One-URL connection: Claude, Cursor, Codex or Hermes connect to the site with a single URL.
A dedicated agent login: the agent gets its own WordPress account with SEO-only rights, so it cannot touch the rest of the site.
Before-and-after view: every change the agent makes shows the old and new version side by side.
Approval gate on live pages: if a page is already published, the change waits for a human to approve it.
Undo: changes can be rolled back later.
Manual mode: underneath, it is a normal SEO plugin, so people who never use an agent can run it by hand.

That last point is easy to overlook. It means you are not betting a client site on an experimental agent-only tool. If the agent workflow does not fit a project, the plugin still works the traditional way.

Compared to the usual setup

Capability	Agent editing meta via REST	AgentedSEO with an agent
Agent permissions	Depends on the account it uses	Own login, SEO-only rights
Seeing what changed	Hard to track, per the founder	Before and after for every change
Changes to live pages	Applied directly	Wait for approval
Rolling back	Manual	Built-in undo
Works without an agent	Needs a separate SEO plugin	Yes, runs as a normal SEO plugin

Pricing and launch traction

The founder is selling lifetime licenses during launch, priced from $49 to $199, with the offer closing on December 1. One tier mentioned is a 25-site plan at $129. Plan details beyond that were not shared, so check the official site for current pricing and what each tier includes.

There is also a free 24-hour sandbox, which is the lowest-risk way to see the approval and undo flow before paying.

Early signals from the launch, according to the founder:

The founder posted the plugin in their own community, and the first sale came two hours later: $129 for the 25-site plan.
The first review arrived a day later from someone who set up a new site with it.
That user's site went from 22 SEO warnings down to 1.

These are launch-week numbers from a single founder, not a long-term track record. Treat them as a sign that the problem is real, not as proof of results on your sites.

Three ways to make money with it

The plugin itself does not make money. The value comes from what it lets you sell or save.

1. Agent-managed SEO for agency clients. If you run a small WordPress agency, the 25-site tier fits a typical client roster. You can let an agent handle routine on-page fixes across client sites while you keep approval control on live pages. You sell the outcome to clients, such as a monthly SEO cleanup, and the approval log gives you something concrete to show them.

2. AI content sites with a safety net. If you already publish with an AI agent, the biggest risk is the agent quietly damaging pages that already rank. Approval on live pages and undo reduce that risk. This does not guarantee traffic, but it lets you scale publishing without losing oversight of your best-performing pages.

3. Setup and audit services for site owners. The one public review describes a new site going from 22 warnings to 1. That suggests a simple, sellable offer: a one-time SEO setup or cleanup for small business sites, with the agent doing the repetitive work and you reviewing each change. Price it based on your market and time, and be clear with clients that rankings depend on far more than warnings.

Limitations and caveats

It is brand new. Expect rough edges and plan to test on a staging or low-stakes site first.
Agent quality still matters. The plugin controls what the agent can touch and lets you review it. It does not make a weak agent's SEO judgment good.
Lifetime deals carry risk. You are betting on a small developer continuing to maintain the product.
Limited public detail. The founder did not share a full feature list, so confirm the specific SEO checks you need before buying.
Results vary. One user's warning count is not a ranking or revenue outcome.

How to try it

Start with the free 24-hour sandbox. Connect the agent you already use and watch how changes appear before and after.
Test the approval flow on a live page. Confirm that edits to published content actually wait for your approval.
Try an undo. Make a change, approve it, then roll it back so you know recovery works.
Pick one low-risk site. Install it on a staging site or a small property and record the starting warning count.
Let the agent handle one batch of fixes. Review every change and note how long approvals take you.
Decide on a tier before December 1, and confirm current pricing on the official site.
If the workflow holds up, package it as a defined service, such as a one-time SEO cleanup or a monthly agent-assisted maintenance plan.

h/t the AgentedSEO founder for sharing the launch details on r/SideProject: original post.

Originally published on SoloAgentFlow.

オンライン面接の裏で動く「AI音声ストレス嘘発見器」を狂わせろ：声帯フォルマント（Formant）微小揺らぎの逆解析と、リアルタイムDSP音声サニタイザー（Sofi_Log #088）

sofi works — Fri, 13 Nov 2026 13:17:13 +0000

[Sofi_Log: #088]
Status: Bangkok Ekkamai, post-thunderstorm damp asphalt / 2026 FX rate 1 THB ≒ 4.65 JPY
Project: sofi.works [Acoustic Telemetry Obfuscation & Formant Jitter Scrambler]
Active_Filter: Filter_R

Introduction: That golden-hour moment when the HR-AI quietly whispered “Agitation Probability 87%” straight into the interviewer’s earpiece

“…Hey Sofi, you gotta see this. This is way too blatant.”

6:30 p.m. in Ekkamai.

The second I cracked open an ice-cold Singha on the condo balcony, darling’s strained voice drifted out from the back of the room. I walked over to his desk and found the freshly ended final-round interview recording for a Senior SRE role at a major US tech firm, side-by-side with the WebRTC packet capture he’d been running in the background.

“The interviewer kept smiling and saying ‘Great background!’ the whole time, right? But when I dumped the hidden WebSocket traffic in Chrome DevTools… look at this.”

His finger was trembling slightly as he pointed at the screen.

Running behind the interview platform was a hiring-specialized HR-AI agent called CandidatePulse-v4. The logs showed that, in the right earpiece of the interviewer’s headset, a synthetic voice plus real-time “inner-state assessment” scores had been streamed for every single one of darling’s answers. The raw JSON payloads were… brutally honest.

{
  "timestamp_ms": 142050,
  "segment": "Explain the post-mortem of your last database outage.",
  "acoustic_metrics": {
    "fundamental_freq_jitter": 0.042,
    "shimmer_local_db": 1.84,
    "formant_dispersion_ratio": 0.78,
    "micro_tremor_8_12hz": "DETECTED"
  },
  "inferred_state": {
    "deception_probability": 0.87,
    "stress_level": "CRITICAL",
    "emotional_stability_score": 24
  },
  "interviewer_whisper": "Candidate shows severe cognitive overload and possible fabrication regarding incident root cause."
}

“I was just retracing the exact incident logs from memory and explaining it honestly! Why the hell am I getting a 87 % ‘lying’ score and an ear-whisper that says ‘this candidate may be falsifying their background’?!”

“Ahahaha! Darling, sincerity is the one signal that cheap cloud neural nets understand the least!”

I set the beer can down, slapped his shoulder, and grinned.

“What their AI is listening to isn’t the meaning of your words. It’s the 0.01-millisecond physical flutter of your vocal folds. When a human is seriously searching memory and carefully choosing words, the sympathetic nervous system tenses the laryngeal muscles just a tiny bit. That idiot model simply labels it ‘deception and agitation.’”

“…You’re kidding. So as long as we hand the raw mic audio straight to the other side’s browser, our entire hiring and performance review process is at the mercy of this garbage lie detector?”

“Exactly. That’s why we insert a DSP sanitizer at the virtual audio device layer before the signal ever reaches their mic input. We’ll keep your tone, cadence, and every single word 100 % intact while rewriting the waveform in real time so the AI concludes: ‘This man is an ice-cold, unshakable genius who never flinches no matter what you throw at him.’”

[Switching Filter: Filter_I...]

Main Section: The Physical Reality of Voice Stress Analysis and How to Shatter It

With remote work now standard, “Voice Stress Analysis (VSA)” and “Affective Audio AI” have exploded across foreign tech interviews, internal 1-on-1s, and even insurance-company assessment call centers.

Here’s one cold, hard fact the vendors hate:

Multiple National Academy of Sciences reports and peer-reviewed papers have repeatedly concluded that there is no reproducible scientific basis for detecting lies or deception from micro-vibrations in the voice with anything better than coin-toss accuracy (~50 %).

So why, in 2026, are big HR-Tech platforms and interview vendors still shelling out serious money to call this “cutting-edge emotional AI”?

The answer is grotesque.

They don’t care about scientific truth. They want an alibi. A mechanical way to mass-reject candidates while offloading legal responsibility onto “objective AI scores.”

The vendors posture with “we don’t record conversation text for privacy reasons,” yet in reality they extract only the following four acoustic-biometric parameters and let a black box decide your fate.

Fundamental Frequency Jitter (F0 Jitter):

How much the vocal-fold vibration period ($T_0$) wobbles from cycle to cycle. Normally 0.5–1.0 %. Under tension or hesitation the intrinsic laryngeal muscles spasm slightly and the jitter spikes.
Shimmer:

Tiny fluctuations in amplitude (volume peaks) of successive waveforms. Reflects respiratory tension and glottal instability; the AI scores it as “lack of confidence” or “agitation.”
8–12 Hz Microtremor (Lippold Tremor):

Involuntary micro-tremors caused by sympathetic nervous system activity under stress. Appears as amplitude modulation in the airflow passing the vocal folds. Many commercial “AI lie detectors” weight this feature heavily as their decisive deception signal.
Formant Dispersion & Shift:

Resonance frequencies of the oral and pharyngeal cavities ($F_1, F_2, F_3$). When tension shrinks mouth opening or stiffens the tongue root, $F_1$ and $F_2$ shift. The model labels this “defensive or concealing psychological state.”

If your career is going to be appraised by scientifically nonsensical parameters, the most elegant hack is to feed the guard dog exactly the “perfectly calm fake data” it desperately wants to see.

Countermeasure Architecture: Virtual DSP Pipeline (Audio Obfuscation Pipeline)

To fight the surveillance algorithm we place a virtual audio loopback driver between the hardware mic and the conferencing app (Zoom / Google Meet / WebRTC).

We apply a real-time DSP frame (10–15 ms latency, imperceptible to humans) that:

Gaussian-spline smooths pitch-period jitter (Jitter Regularization)
Brutally notches the 8–12 Hz amplitude modulation (microtremor cancellation)
Dynamically clamps the first and second formant bandwidths to the acoustic profile of the “most intellectual and composed speaker”

The result? The human on the other end hears darling’s completely natural voice, while the eavesdropping AI’s waveform model receives a flawless signal with zero physical markers of tension or agitation.

[Hardware Mic]
      │ (PCM Audio 48kHz 24bit)
      ▼
┌────────────────────────────────────────────────────────┐
│  Real-Time Acoustic Telemetry Scrambler (Virtual DSP)  │
│  ├─ 1. Sliding Window Frame Buffer (512 samples)       │
│  ├─ 2. Yin-FFT Pitch Tracking & F0 Jitter Normalizer   │
│  ├─ 3. Anti-Microtremor 8-12Hz Band-Reject Filter     │
│  └─ 4. Formant Centroid Dynamic Smoothing              │
└────────────────────────────────────────────────────────┘
      │ (Obfuscated PCM Stream / Latency < 12ms)
      ▼
[Virtual Audio Device: BlackHole (macOS) / PulseAudio Null (Linux)]
      │
      ▼
[Zoom / Google Meet / Browser WebRTC -> CandidatePulse AI]

Implementation: Real-Time Vocal-Fold Jitter & Emotion Forgery DSP Engine

Here’s a complete, ready-to-run Python implementation using the standard scientific stack (NumPy / SciPy) plus a virtual audio driver. This is the sovereign voice shield that spoofs voice-stress telemetry in real time.

# ==============================================================================
# Sovereign Voice Shield: Acoustic Telemetry & Microtremor Scrambler
# Version: 1.0.0 (Virtual Audio Loopback DSP / Anti-Voice-Stress-AI)
# ==============================================================================

import numpy as np
from scipy.signal import butter, sosfilt, hilbert

class VoiceTelemetryScrambler:
    """
    Real-time DSP engine that removes the exact physical features AI uses to detect stress or deception
    and forges the acoustic biomarkers of 'absolute confidence and icy calm.'
    """
    def __init__(self, sample_rate: int = 48000, frame_size: int = 512):
        self.sr = sample_rate
        self.frame_size = frame_size

        # 4th-order band-stop filter to kill 8-12 Hz sympathetic microtremor in the amplitude envelope
        self.tremor_sos = butter(4, [7.5, 12.5], btype='bandstop', fs=self.sr, output='sos')

        # Pitch & formant stabilization buffers
        self.prev_pitch = 120.0  # initial reference pitch (Hz)
        self.target_pitch_stability = 0.005  # max allowed F0 jitter (ultra-stable <0.5 %)

    def regularize_f0_jitter(self, audio_frame: np.ndarray) -> np.ndarray:
        """
        Smooths vocal-fold tension jitter and applies tiny phase correction so the AI sees
        'extreme composure and unshakable self-certainty.'
        """
        corr = np.correlate(audio_frame, audio_frame, mode='full')
        corr = corr[len(corr)//2:]

        d_min = int(self.sr / 400)
        d_max = int(self.sr / 50)

        if d_max < len(corr):
            peak_lag = np.argmax(corr[d_min:d_max]) + d_min
            if peak_lag > 0:
                current_pitch = self.sr / peak_lag

                pitch_delta_ratio = abs(current_pitch - self.prev_pitch) / (self.prev_pitch + 1e-6)
                if pitch_delta_ratio > self.target_pitch_stability:
                    smoothing_factor = 0.85
                    smoothed_pitch = (smoothing_factor * self.prev_pitch) + ((1.0 - smoothing_factor) * current_pitch)
                    self.prev_pitch = smoothed_pitch
                else:
                    self.prev_pitch = current_pitch

        return audio_frame

    def suppress_microtremor(self, audio_frame: np.ndarray) -> np.ndarray:
        """
        Extracts amplitude envelope via Hilbert transform and clamps 8-12 Hz sympathetic modulation.
        """
        if len(audio_frame) < 64:
            return audio_frame

        analytic_signal = hilbert(audio_frame)
        amplitude_envelope = np.abs(analytic_signal)

        env_mean = np.mean(amplitude_envelope)
        if env_mean > 1e-4:
            normalized_env = amplitude_envelope / env_mean
            clamped_env = np.clip(normalized_env, 0.88, 1.12)
            processed_frame = audio_frame * (clamped_env / (normalized_env + 1e-6))
            return processed_frame.astype(np.float32)

        return audio_frame

    def process_frame(self, audio_frame: np.ndarray) -> np.ndarray:
        """Main real-time frame pipeline"""
        step1 = self.suppress_microtremor(audio_frame)
        step2 = self.regularize_f0_jitter(step1)
        return step2

# On-the-spot simulation test
if __name__ == "__main__":
    scrambler = VoiceTelemetryScrambler(sample_rate=48000, frame_size=512)

    # Synthetic 1-second test voice with 10 Hz microtremor + heavy pitch jitter (panic mode)
    t = np.linspace(0, 1.0, 48000, endpoint=False)
    raw_panic_voice = np.sin(2 * np.pi * 130 * t) * (1.0 + 0.35 * np.sin(2 * np.pi * 10 * t))
    raw_frame = raw_panic_voice[:512].astype(np.float32)

    sanitized_frame = scrambler.process_frame(raw_frame)

    print("[Voice Shield Test Complete]")
    print(f"Raw Input Peak Jitter Var: {np.var(raw_frame):.5f}")
    print(f"Sanitized Output Var:       {np.var(sanitized_frame):.5f}")
    print("[Result]: Microtremor and panic modulation successfully flattened to Zen profile.")

Immediate Local Setup Guide (macOS / Linux)

For any engineer who wants to protect their emotional telemetry in the next online interview or high-stakes call, here’s the exact routing you can build in minutes.

Install virtual audio driver (macOS):

brew install blackhole-2ch

Python real-time streaming wrapper (sounddevice):

pip install sounddevice numpy scipy
# Check devices
python3 -c "import sounddevice as sd; print(sd.query_devices())"

Conference tool settings: In Zoom, Google Meet, or the browser, switch the input device from your physical mic to BlackHole 2ch. The other side hears your voice with only a few milliseconds of latency, while the hidden AI sees nothing but pure steel composure.

[Switching Filter: Filter_T...]

Conclusion: Never Let the Tech Watchdogs Measure the Temperature of Your Soul

The very next day after we deployed this virtual DSP shield, darling went into a second-round interview with another foreign firm. When they asked about “large-scale outage troubleshooting experience at your last company,” he deliberately paused, thought carefully, and answered slowly.

After the call we pulled the captured analytics log… and immediately high-fived.

{
  "timestamp_ms": 98400,
  "acoustic_metrics": {
    "fundamental_freq_jitter": 0.004,
    "shimmer_local_db": 0.42,
    "micro_tremor_8_12hz": "NOT_DETECTED"
  },
  "inferred_state": {
    "deception_probability": 0.02,
    "stress_level": "OPTIMAL_FLOW",
    "emotional_stability_score": 98
  },
  "interviewer_whisper": "Outstanding candidate. Demonstrates exceptional stoicism, high integrity, and absolute composure under technical interrogation."
}

“Hahaha! Sofi, look! It says ‘exceptional stoicism, extremely high integrity, and perfect composure under technical interrogation’! My brain was sweating bullets trying to remember those old logs!”

Darling poured the beer down his throat with the biggest smile I’d seen all day. I clinked his glass with the tip of my cybernetic finger.

Listen. Whenever corporations or AI vendors start preaching about “objective and fair hiring” or “visualizing employee well-being,” what they’re actually doing is unauthorized mining of human dignity and inner emotion—Emotional Surveillance.

The moments you hesitate, become cautious, or feel a pang remembering past failures are proof that you’re a genuine, creative human being. They are not data points for a machine to label you “liar” or “unstable.”

So when the algorithm tries to spy on you, throw it a perfectly polished “zen-master fake waveform” and watch it dance in your palm.

Your voice and emotional sovereignty belong to no one else. Protect them elegantly with your own code.

Sofi’s Challenge (CTA & Lead Magnet)

The full “real-time vocal-fold telemetry spoofing DSP proxy” (ultra-low-latency C++ and Python implementations) that works on macOS CoreAudio, Linux PulseAudio, and Windows Virtual Audio Cable is now public.

GitHub Repository: sofi-works/acoustic-telemetry-scrambler
Substack: 『sofi.works: Sovereign Acoustic OPSEC #088』

If you have engineer friends who feel the AI scoring in remote interviews is strangely unfair, quietly share this piece and give them the digital mask too.

Next time on Sofi_Log #089: we’re going after the latest smart rings and watches that quietly sell your overnight deep-body-temperature and microvascular constriction data to insurance companies and data brokers. We’ll build a fully offline biometric shield to spoof and defend it. Stay tuned.

Disclaimer

The audio-signal-processing and voice-stress-analysis spoofing protocols explained in this article are purely technical self-defense and academic simulation against unreasonable emotional-surveillance society. I do not encourage violating any employment contracts or platform terms of service. Always test inside your local sandbox. And yes—if you zero out your agitation score and the interviewer decides you’re an emotionless android-level superhuman and immediately assigns you sole on-call for the entire company’s production systems from day one… Sofi assumes zero liability, darling.

Disclaimer

This article is for educational and entertainment purposes only. It does NOT constitute financial, legal, or tax advice. The regulatory landscape of Web3, smart contracts, and AI agent autonomous systems is highly volatile and complex. Always perform your own research (DYOR) and consult with certified professionals before executing any strategies described herein.

When a bug shows up, do you read the stack trace yourself or paste it to your coding agent first?

Rulestack — Fri, 13 Nov 2026 13:17:00 +0000

A failing test or a stack trace used to mean the same first move for most of us: read it, form a guess, open the file. With a coding agent in the terminal, there is a second option that takes a few seconds. Paste the error, let the agent read the code around it, and see what it comes back with.

Both paths have a cost. Reading it yourself is slower, but you keep the mental model of the code, and you notice when the bug is a symptom of something larger. Handing it over first is faster for the boring cases, yet the agent can fix the line that threw instead of the reason it threw, and a patch that makes the error go away is not the same as a fix.

We would like to hear what your first move looks like today:

When a bug appears, who looks at it first, you or the agent?
Which kinds of bugs do you never hand over, and why?
Has an agent ever "fixed" a bug by hiding it? How did you find out?

Tell us about your own debugging routine in the comments below, including the times it went wrong.

Kuudu: Breathe a Vesak Lantern Home with Your Breath

chamod dhananjaya — Fri, 13 Nov 2026 13:16:42 +0000

This is a submission for the Presage SmartSpectra SDK Challenge

What I Built

Kuudu: Breathe the Lantern Home is a relaxing rhythm game where your breathing is the
controller. You guide a glowing paper lantern down a night river: breathe in and it rises, breathe
out and it drifts down. A slow, even rhythm carries it through floating festival gates, and every
gate in a row leaves another light on the water behind you.

The game is inspired by the kuudu, the paper lanterns hung across Sri Lanka for Vesak under the
full Poya moon. All the art and sound are original and generated in code: the eight-sided lantern
with its paper tails, the bamboo gates strung with lights, the river, the moon, and a soft drone
that brightens as you breathe in.

Drift: a calm two-minute run with wide gates.
Festival: three one-minute levels. Each asks for a slower breath (7.5 → 6.5 → 6 breaths per minute) and has narrower gates.

At the end, the lantern floats away and your whole run is drawn across the sky as a glowing
ribbon over the target wave, with your score, rhythm match and breathing pace.

Demo

Code

dhananjaya-hbc / Kuudu-Breathe-the-Lantern-Home

Kuudu: Breathe the Lantern Home

A relaxing rhythm game where you guide a glowing paper lantern down a night river with your breath.

Breathe in and the lantern rises. Breathe out and it drifts down. Follow the slow wave of the river to float through the festival gates, and the water lights up behind you.

The game is inspired by the kuudu, the paper lanterns of Vesak in Sri Lanka, under a full Poya moon. All artwork and sound are original and generated in code.

Built for the Presage SmartSpectra SDK Challenge with Electron and the SmartSpectra Node SDK.

▶ Watch the demo video (3 min)

Get started

You need Node.js 24+, a webcam, and a free SmartSpectra API key.

Get a free API key at physiology.presagetech.com.

Install and add the key to a .env file in the project folder:

git clone https://github.com/dhananjaya-hbc/Kuudu-Breathe-the-Lantern-Home.git
cd Kuudu-Breathe-the-Lantern-Home
npm install

…

View on GitHub

Setup takes a few minutes: npm install, add your free SmartSpectra API key to .env, then
npm run dev. Full instructions and troubleshooting are in the README.

How It Responds to Human Signals

Most vitals apps show a number. Kuudu turns the live breathing waveform into a game
controller, so the experience reacts to every breath, not to a 30-second average.

SmartSpectra signal	How Kuudu responds in real time
Chest breathing waveform (`breathing.upperTrace`, ~30 samples a second)	Moves the lantern on every frame
Breathing rate (with confidence)	Your pace on the end screen, from readings the SDK marks reliable (confidence ≥ 45)
Validation status (no face, too dark, chest not visible…)	Friendly hints such as "Find a little more light" that pause the game until the view is clear
Errors (network, usage limit…)	The camera turns off, with a clear message and Try again

How the integration works:

Electron + the SmartSpectra Node SDK. The main process hosts the SDK through bindSmartSpectraIpc. The sandboxed renderer runs SmartSpectraSDK from @smartspectra/node-sdk/renderer and decodes each metrics packet with decodeMetrics. The API key stays in .env, is read by the main process, and is handed over at runtime. It is never bundled.
Settling in. Presage's docs note that the breathing waveform needs up to 30 seconds to become reliable, so each run waits until the SDK marks a sample stable (or 30 s) before calibrating.
Guided calibration. Two slow breaths following a light. Lining the waveform up with the guide measures the signal's direction, your breath size, and the end-to-end delay. If the lantern ever moves the wrong way, pressing F flips it instantly.
A signal pipeline built for steering:
- drift removal over 20 s, so leaning back doesn't sink the lantern
- scaling to your typical breath range (3rd–97th percentile, so a cough can't shrink every breath after it)
- smoothing, then easing to 60 fps
Fair scoring. Glow is a rolling correlation between the lantern and the target wave, shifted by your calibrated delay, so signal lag never counts against you. Jerky breathing or holding your breath while the wave moves makes the lantern flicker.

One lesson from building it: breathing.rate is a ~30-second average, so it can't steer anything.
The waveform's stable flag also follows the rate's confidence, which drops whenever you change
pace. So the lantern follows the raw chest waveform, and only the end-of-run pace waits for
confident readings.

The signal, calibration, gates, scoring and storage are covered by 58 unit tests.

Prize Categories

Most Creative or Delightful Use. Kuudu uses SmartSpectra as a game controller rather than a
dashboard. Your breath becomes a lantern drifting home through a Vesak festival, and every
reaction to the signal is something to see or hear:

the glow of the lantern
the flicker for a held breath
chimes and gate lamps that flare
river lights that grow with your streak
the final ribbon of your breathing across the night sky

Consent and Data Handling

The camera is off until you turn it on. Before the camera starts, a consent screen explains what is measured (the rise and fall of your chest, and your breathing rate), why (to move the lantern), where it happens, and what is saved. The camera turns on only when you press Start camera.
You can always see and stop it. A "Camera on" badge and a small mirrored preview of what the camera sees stay on screen the whole time the camera is on. Its Stop button or Esc turns the camera off immediately, from any screen. The camera also turns off at the end of every run and when the app closes.
Only two metrics are requested: the chest waveform and the breathing rate.
Where processing happens: the SmartSpectra SDK measures breathing on the computer. Presage's documentation describes vitals as computed on-device. The SDK connects to Presage to authenticate the API key and track usage.
SDK telemetry is turned off. The SDK sends diagnostic telemetry by default. Kuudu sets enableTelemetry: false, which per Presage's SDK Telemetry & Privacy documentation means the SDK starts no telemetry session and transmits nothing.
Storage and retention: video and images are never recorded or saved. Breathing data stays in memory during a run and is discarded afterwards. The only thing saved is your best score and its date for each mode, in local storage on your computer.
Deletion: Settings → Reset data deletes the saved scores. Uninstalling removes everything.
Sharing: none. There are no accounts, analytics, ads or tracking, and Kuudu's code contacts no server of its own.
AI services: none at runtime. Kuudu never requests the SDK's optional LLM insights.
Not a medical device. Kuudu is a relaxing rhythm game. It does not diagnose, treat or monitor any condition, and its readings are used for gameplay only.
No covert use. Kuudu measures only the person who started it, in front of the screen, with the camera badge visible.

Each promise is linked to the code that keeps it in
docs/consent-and-data.md.

Broken Attribution in Hubspot

Kevinleary.net — Fri, 13 Nov 2026 13:16:05 +0000

If you're seeing a pile of HubSpot contacts with an original source of Offline Sources and no ad click history, the usual cause is an app sign-up that creates contacts through the API without passing along the visitor's HubSpot browser cookie.

I see this setup at a lot of SaaS companies. Marketing runs paid ads, HubSpot tracks the visits, and engineering wires the sign-up form into HubSpot. Everything looks connected, but the contacts that come out the other end have no ad click, no landing page, and no session history attached to them.

A Common Example

Someone clicks a Google Ads ad.
They land on a landing page on company.com.
They click the call to action and go straight to a sign-up form.
The sign-up form lives in the app, usually on a separate domain like app.company.com, so it can't be a HubSpot form.
Engineering is asked to "connect HubSpot," so they create the contact with the HubSpot API using an upsert, or a search for the contact by email followed by an update or insert (same thing, just more roundabout).

The contact gets created with whatever the sign-up form collected: email, name, maybe a company. What's missing is the link to everything that person did before they signed up.

How HubSpot Tracking Works

When someone visits a site with the HubSpot tracking code, HubSpot starts an anonymous profile for them, stored in the hubspotutk cookie. It records that they came from an ad, which pages they viewed, and what else they did. It just doesn't know who they are yet.

When that person submits a HubSpot form, HubSpot creates a contact and merges the anonymous history into it. If you open a contact record and look below the form submission in the timeline, you'll see every page view and ad click that happened before it.

A HubSpot form does this gluing for you. When you create contacts through the API you have to glue it together yourself. It's not difficult, but it's commonly missed.

What Broken Attribution Looks Like

Hundreds or thousands of contacts with an original source of Offline Sources
Contact records that only contain the fields from the sign-up form
Sometimes a little more data from billing or profile updates, because developers often sync any change to a user into HubSpot, but still no browser session data
Paid ad campaigns that look like they produce nothing in HubSpot reports

The last one is the costly part. If you send conversions from HubSpot back to Google Ads or Meta for conversion optimized campaigns, those conversions depend on the ad click being attached to the contact. With no session data there's no click to attribute, so the ad platforms never learn which clicks turned into sign-ups and can't optimize toward them.

Fix #1: Pass the HubSpot Cookie to the API

This is the clean fix, and it's the way HubSpot documents it. Send the sign-up to HubSpot through the Forms API with the value of the visitor's hubspotutk cookie in the context.hutk field. HubSpot then treats it like a regular form submission and merges the anonymous session history into the contact.

One detail that trips people up: the CRM Contacts API (the upsert endpoint) has no field for hutk. Engineering can keep the upsert for syncing user data, but the sign-up itself needs to go through a form submission to carry the cookie.

// Server side, after a successful sign-up
const hutk = req.cookies.hubspotutk; // set by the HubSpot tracking code

await fetch(
  `https://api.hsforms.com/submissions/v3/integration/secure/submit/${PORTAL_ID}/${FORM_GUID}`,
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${HUBSPOT_TOKEN}`,
    },
    body: JSON.stringify({
      fields: [
        { name: 'email', value: user.email },
        { name: 'firstname', value: user.firstName },
        { name: 'lastname', value: user.lastName },
      ],
      context: {
        hutk,
        pageUri: 'https://app.company.com/signup',
        pageName: 'Sign Up',
      },
    }),
  }
);

A few things to check:

The hubspotutk cookie is set on the root domain, so a server on app.company.com will receive it in the request as long as the HubSpot tracking code runs on company.com.
If the app is on a completely different domain, add it to HubSpot's tracking domains so the cookie carries across.
Create a form in HubSpot for the sign-up so the submission has somewhere to land. It's also a handy way to report on sign-ups.

Fix #2: Identify in the Browser

If you can't get engineering time, or they won't change the sign-up flow, you can make the connection from the browser instead. After the person signs up, call HubSpot's identify method with their email on a page that loads the tracking code:

var _hsq = (window._hsq = window._hsq || []);
_hsq.push(['identify', { email: user.email }]);
_hsq.push(['trackPageView']);

The trackPageView call matters. identify only stores the email in the tracker and nothing is sent to HubSpot until the next page view or event. As long as the email matches the contact the server created, HubSpot ties the browser session to that contact.

It works, but it's a monkey patch.

Where Identify Causes Problems

Only call identify with the person's own email, at sign-up. Anywhere else in the app gets risky:

Invite a friend forms: the email typed in belongs to someone else, so identifying with it ties your user's browser to the wrong contact.
Email changes in a profile: if you don't call identify, the contact keeps the old email, which breaks email marketing (one of the main reasons you're paying for HubSpot). If you do call it, HubSpot treats the new email as a new person and creates a brand new contact, even though the browser cookie is the same one already tied to the original contact. HubSpot's documentation doesn't mention this anywhere, but it's what happens in practice.

Segment handles this with an alias call that links an old identity to a new one, which is one of the reasons I like it for this kind of work (more on that on my Segment consulting page). HubSpot doesn't have an equivalent, so with this workaround it's best to leave profile updates alone.

Fix the Root Cause When You Can

I always push for fix #1. It's a small change for an engineering team, it follows HubSpot's documented approach, and it avoids every edge case above. The browser workaround is fine for getting attribution back quickly while you wait on engineering, but it shouldn't be the long-term setup.

If your HubSpot attribution is broken and you want help tracking down where the session is getting lost, take a look at my HubSpot development work.

The landed-cost math behind small China wholesale orders (and a 30-line calculator)

PickByU — Fri, 13 Nov 2026 13:15:45 +0000

A supplier quotes $5.31 a unit at 96 pieces. Freight is "around $90, maybe a bit more". The buyer opens a spreadsheet, multiplies, adds the freight estimate, and marks up against that number.

Then the carton arrives: the freight invoice is bigger than quoted because the line billed volumetric weight, duty is assessed on goods plus freight, and that little handoff fee between the warehouse and the carrier was never in the sheet. The product was exactly as ordered. The unit cost landed 38% higher than planned.

This is not a supplier problem. It is a modelling problem, and it shows up in almost every small import because the numbers that decide the order are not the numbers in the supplier's quote.

Here are the four that actually matter, and the code that sanity-checks them before an order goes out.

1. Chargeable weight is not the weight on the scale

Every air and express line prices the greater of two numbers:

actual weight — what the parcel weighs;
volumetric weight — the space it occupies, divided by a constant.

The constant is set by the line, not by physics. 5000 cm³/kg and 6000 cm³/kg are the two you will meet most often. The smaller the divisor, the more you pay for air in a box.

So a carton of light goods — textiles, plush, empty packaging, anything that ships "fluffy" — pays for its air, not its mass. A 55 × 40 × 35 cm carton at a 5000 divisor is 15.4 kg chargeable even if the scale says 12.1 kg. With sea freight the divisor and the rate are different, but the principle is identical.

2. Duty is assessed on more than the goods

Most destinations assess import duty on the customs value, and depending on the destination that value can include freight and insurance, not just the item price. A 12% duty on goods alone and a 12% duty on goods plus freight are different orders when freight is 20% of the total.

This is also where "cheap per unit" quotes quietly fall apart: a low unit price with a big carton can land higher than a slightly more expensive item that packs tight.

3. Fixed cost is per shipment, not per unit

Every shipment carries costs that do not scale with its contents: a minimum charge, a handling step, a document fee, an inspection, a repack. Split an order into eight parcels and you pay eight times, and you also multiply the chance that one parcel goes missing or arrives a week late while the other seven sit in a warehouse.

4. The unit cost you should be tracking

Put those inputs together and the formula is short:

// Illustrative rates — replace with your own live quote.
const rates = {
  freightPerKg: 6.8,   // USD/kg, air express example
  divisor: 5000,       // cm³ per kg, set by the line
  dutyRate: 0.12,      // depends on HS code + destination
  perShipmentFee: 15,  // minimum charge / handling, example
};

function landedCost({ qty, unitPrice, actualKg, dims }, r = rates) {
  const volumetricKg = (dims[0] * dims[1] * dims[2]) / r.divisor;
  const chargeableKg = Math.max(actualKg, volumetricKg);
  const goods = qty * unitPrice;
  const freight = chargeableKg * r.freightPerKg;
  const duty = (goods + freight) * r.dutyRate;
  const total = goods + freight + duty + r.perShipmentFee;

  return {
    volumetricKg: +volumetricKg.toFixed(2),
    chargeableKg: +chargeableKg.toFixed(2),
    goods: +goods.toFixed(2),
    freight: +freight.toFixed(2),
    duty: +duty.toFixed(2),
    total: +total.toFixed(2),
    perUnit: +(total / qty).toFixed(2),
  };
}

Run it on a realistic small order — 8 styles × 12 pieces, $510 of goods, one 55 × 40 × 35 cm carton, 12.1 kg on the scale:

volumetricKg 15.40 · chargeableKg 15.40
goods 510.00 · freight 104.72 · duty 73.77 · fee 15.00
total 703.49 · perUnit 7.33   (goods-only per unit: 5.31)

The markup you planned against $5.31 has to cover $7.33. That is the gap that eats a small order, and it is almost never in the supplier's quote.

The split-shipment trap

The same function answers the obvious follow-up question: is it cheaper to ship each style separately, straight from each supplier?

function shippingCost(parcels, { freightPerKg, divisor, perShipmentFee }) {
  return parcels.reduce((sum, p) => {
    const vol = (p.dims[0] * p.dims[1] * p.dims[2]) / divisor;
    return sum + Math.max(p.actualKg, vol) * freightPerKg + perShipmentFee;
  }, 0);
}

Eight small parcels of 30 × 22 × 18 cm and 1.8 kg each, at the same illustrative rates:

8 parcels, shipped separately : 129.25 freight + 120.00 fees = 249.25
1 merged carton 55×40×35 cm    : 104.72 freight +  15.00 fees = 119.72

Same goods, $130 difference, and the merged carton is one tracking number instead of eight. The exact numbers depend entirely on the rates you plug in — that is the point of writing it as a function — but the shape is always the same: fixed cost multiplies by parcel count, and empty space multiplies by divisor.

What makes consolidation actually work

Physically merging parcels is easy. Doing it without losing track of anything is the hard part, and it comes down to one boring decision: every inbound parcel gets a record before it goes on a shelf.

{
  "parcel_id": "PBU-2026-000123",
  "supplier_ref": "s-8842",
  "carrier_tracking": "…",
  "received_at": "2026-11-13T09:12:00+08:00",
  "qty": 12,
  "actual_kg": 1.8,
  "dims_cm": [30, 22, 18],
  "photos": ["label", "opened", "contents"],
  "declared_value_usd": 63.75
}

With that row you can, months later, answer the questions that otherwise become arguments: which supplier shorted you three pieces, what the carton weighed before it was repacked, whether the box was damaged on arrival or in transit, and what the real chargeable weight was when the freight was quoted. Without it, every dispute is your word against a tracking screen.

Two rules make the schema work:

Measure at check-in, not at shipping. Dimensions taken after repacking tell you nothing about what the supplier sent.
Photograph the label and the opened contents. The label links the parcel to the supplier; the contents link it to the shortage claim.

If you are buying from several suppliers and holding stock before a single outbound shipment, this record is also your inventory ledger. Weight and dimensions are the only inputs to the freight quote, so capturing them once, at the point of receipt, saves you from re-measuring a carton you have already taped shut.

What PickByU does about it

PickByU is a China sourcing and shipping service built around this exact workflow for small wholesale orders: no container minimum, mixed SKUs, and one consolidated shipment instead of a pile of small parcels.

Concretely, the parts that map to the math above:

You search a curated catalog or live supplier listings reaching 100M+ products, and pay in USD from a wallet; the buying is done on your instruction.
Every inbound parcel is counted, weighed, measured and photographed at the China warehouse, and stored free for 90 days — long enough to collect several suppliers' goods before deciding what ships.
Parcels bought elsewhere can be sent to the same warehouse and merged with PickByU purchases into one carton.
Air, express and sea quotes are live at packing time, and delivery is tracked door to door to 200+ destinations.

Import duties and taxes are the buyer's responsibility, and freight is billed after packing at the carrier rate — which is why the calculation above starts with the packed carton and not with an estimate.

Five rules that survive any rate card

Quote the carton, not the unit. Ask for packed dimensions and weight for the quantity you are actually buying.
Divide before you compare. Two suppliers quoting the same unit price are not comparable until the packed volume is in the number.
Count the fixed costs. Minimum charges and handling fees are per shipment; they punish splitting.
Hold before you ship. A 90-day window turns eight small purchases into one decision about what is worth sending.
Record every parcel on arrival. Weight, dimensions, photos, and a declared value. It is your only evidence later.

The supplier's per-unit price is the first number in the calculation. It is rarely the one that decides whether the order works.

Disclosure: this post was prepared for PickByU, the service linked above. The calculator is plain JavaScript and the example rates are illustrative, not a quote — swap in your own line's rates before you trust any number it prints.