StackOnward

What Is Jev AI? It Picks an Agent’s Next Move

Sat, 19 Sep 2026 13:15:00 +0800

Jev AI has had a ridiculous week. jev-ultrafast(opens in a new tab) passed 6,400 GitHub stars less than three days after it was created, while Jev projects for Mac and Android control, coding-agent routing, and code review appeared one after another. Jev(opens in a new tab) is TypeSafe’s model for questions where software can define the possible answers in advance. It returns a choice, score, or probability instead of writing an open-ended response.

What does Jev return instead of text?

A generative model often explains the page or Git diff before answering. Software may need only one action: which button should it click next? Once the model finishes writing, the program still has to extract that action from the response.

Go Live with Payments: From Sandbox Keys to the First Real Order

Fri, 11 Sep 2026 05:24:00 +0800

The checkout page already uses a live key, but the subscription still cites a test Price. After the customer pays, the production webhook fails signature checks because it still uses the sandbox secret. Mixed config does not fail together: some errors stop before payment, others wait until money has moved, then order, entitlements, and finance stop in different states.

The cutover order is: fence entries that create captures and refunds; attach account, keys, Price, webhook, domain, workers, and finance to live together; use read-only requests, test events, and return-URL checks to catch environment errors; then open the first real order under provider rules. If that first order fails, close new transactions. Webhooks, lookups, and reconciliation keep running.

Why Payment, Attempt, and Transaction Must Stay Separate

Fri, 11 Sep 2026 05:22:00 +0800

Payment, Attempt, and Transaction amounts cannot be added together. Payment stores owner and target amount for one local collection. Attempt stores the conditions and progress of one accepted operation. Transaction stores the result of one channel money action. A failed try followed by a succeeded retry can leave two execution records and only one amount received.

Keeping only the latest state on one row lets a retry overwrite the last failure, lets a refunded net hide the original capture, and leaves a back-office “success” that cannot say whether money was captured. Separate records answer how many times the customer tried, how much the channel actually captured, and how much was later returned.

Payment Domain Model: Order, Payment, Attempt, and Transaction

Fri, 11 Sep 2026 05:20:00 +0800

A purchase can capture successfully while the workspace stays “provisioning.” Charging again does not fix that. Find the fulfillment record for the original order, and why it did not finish.

A payment domain model stores sale terms, execution, and money results as separate identities. Quote freezes the payable amount. Order stores what both sides confirmed. CheckoutSession and execution records manage the collection process. Payment is the local payment. Transaction stores the result of a specific money action. Provider objects attach through their own identity map. Refunds and fulfillment then point at confirmed purchase and money records. One paid field cannot replace those links.

How to Troubleshoot a Slow Website: DNS, TTFB, and LCP

Fri, 11 Sep 2026 05:18:00 +0800

How to troubleshoot a slow website starts with the URL, the time window, and who is affected. Split one load into DNS, connection, TLS, waiting for the first byte, body download, and rendering. Hosting, CDN, database, and frontend changes only help after that interval has an owner.

curl locates network and first-byte time. Origin metrics and the browser timeline explain the remaining wait.

Start troubleshooting a slow website from the affected URL

Record the incident before opening a profiler:

What Happens When You Type a URL in the Browser

Fri, 11 Sep 2026 05:18:00 +0800

What happens when you type a URL in the browser is a sequence of hops, not a round trip to one origin. The request usually travels through DNS, a TCP or QUIC connection, TLS, a CDN or reverse proxy, and only then the application. The HTML that comes back is not the end; the browser still fetches styles, scripts, fonts, and images. MDN’s account of how the web works(opens in a new tab) lists DNS, the HTTP request, the server response, and the browser assembling the page as consecutive stages.

Caddy vs Nginx vs Nginx Proxy Manager

Fri, 11 Sep 2026 05:15:00 +0800

Caddy vs Nginx is decided by where the reverse-proxy config lives and how certificates are renewed, not by a public request-per-second ranking. A small site with files in Git and default automatic HTTPS usually belongs on Caddy. Working Nginx configs, modules, or operator muscle stay on Nginx. A web UI for a handful of hosts is Nginx Proxy Manager, and that choice also means backing up an application, a database, and generated Nginx files.

Existing Nginx assets stay on the file path. A GUI path still needs a backup of the admin data.

Caddy vs Nginx is decided by the config source of truth

Axis	Caddy	Nginx	Nginx Proxy Manager
Daily config	Caddyfile or JSON	Nginx config files	Web admin UI
HTTPS	Certificate issue and renewal are default	Usually Certbot, acme.sh, or a cloud certificate	Common certificate actions in the UI
Git	Reviewed as files	Reviewed as files	Main state lives in a database
WebSocket	HTTP reverse proxy handles the usual upgrade	Upgrade-related headers must be set correctly	Follows the generated Nginx config
Cache and limits	Configurable	Mature and fine-grained	Bounded by the UI and Advanced config
Extra state	Config plus certificate storage	Config, certificates, and related scripts	App, database, certificates, and generated config

Files are easy to review and roll back. A database is easy to click through, and a restore has to cover that database together with the certificates.

Docker Compose Production: Images, Health Checks, Secrets

Fri, 11 Sep 2026 05:12:00 +0800

Docker Compose production on one host is a pinned image, durable data, a private app port, resource caps, and a stack that returns after a container or host restart. docker compose up -d only reports that the containers started.

The public internet should reach only the reverse proxy on 80/443. Keep the app port on loopback or on the container network.

When Docker Compose production is the right fit

Compose can run production when the whole stack lives on one machine, the service graph is small, and a host failure is recovered by a person or a script on another machine:

How to Configure Docker Volume Permissions and Secrets

Fri, 11 Sep 2026 05:12:00 +0800

How to configure Docker volume permissions starts with a numeric UID and GID match, not a matching username. Put database files and other container-generated state on a named volume, bind-mount host-managed config read-only, and grant each secret only to the service that reads it as a file. Recreate the container to prove the mount. Restore a backup in a separate environment to prove the backup.

Named volumes hold writable state. Bind mounts hold host-managed config. Secret files are granted per service.

Choose a named volume, bind mount, or tmpfs

Type	What belongs there	Why	Main risk
Named volume	Databases, queues, application state	Docker manages the lifecycle; the path is not tied to one host layout	Host backup and migration must name the volume and its driver
Bind mount	Caddyfile, explicit data directories, host scripts	The path is visible to existing backup and permission tools	The host path, owner, and SELinux or AppArmor labels all have to match
tmpfs	Short-lived sensitive files or fast scratch data that must not persist	Nothing is written to durable disk	A restart drops the files; the size counts against container memory

Docker storage(opens in a new tab) treats volumes(opens in a new tab) as the default for data a container generates. Bind mounts(opens in a new tab) are for files the host already owns. tmpfs(opens in a new tab) stays in host memory and is gone when the container stops. The image writable layer is the wrong place for runtime data: deleting the container deletes that layer.

How to Troubleshoot 502 and 504 Behind a Reverse Proxy

Fri, 11 Sep 2026 05:08:00 +0800

How to troubleshoot 502 and 504 starts at the hop that produced the status. Both codes come from a gateway or reverse proxy: 502 Bad Gateway means that hop did not get a usable response from upstream; 504 Gateway Timeout means it waited past its limit. Keep the headers, then reach the upstream from that hop’s network.

Connection refused, DNS failure, and an invalid response usually point to 502. An upstream wait past the proxy deadline usually points to 504.

How to troubleshoot 502 and 504 at the hop that returned the status

A browser may sit behind Cloudflare or another CDN, a cloud load balancer, and Caddy or Nginx. Save the status, headers, time, and request ID:

Why Payment Methods Are Not Showing at Checkout

Fri, 11 Sep 2026 05:08:00 +0800

RouteNest’s Pro monthly checkout produced three results. A Dutch buyer paying in EUR on desktop saw iDEAL and cards. A US buyer paying in USD saw cards plus Apple Pay or Google Pay. The same US buyer opening the page from a limited in-app WebView lost the wallet buttons. Why payment methods not showing at checkout for one customer, while another still sees them: each method has to pass the current account, this order, the buyer’s device, and this page’s settings. Change one of those, and the list can change.

Automatic HTTPS Certificate Renewal with Caddy and ACME

Fri, 11 Sep 2026 05:05:00 +0800

Automatic HTTPS certificate renewal in Caddy is not a cron job. Caddy obtains a certificate, serves HTTPS, redirects HTTP, and renews in the background when the hostname, public DNS, ACME challenge path, and certificate storage all work. A running Caddy process does not prove the next ACME attempt will succeed.

After issuance, the certificate, private key, and ACME account state are written to the data directory. Background renewal uses the same challenge path.

Automatic HTTPS certificate renewal only starts when these conditions hold

Caddy’s Automatic HTTPS documentation(opens in a new tab) requires all of the following at once:

Automatic rollback for a failed deployment: transaction state, traffic switch, and rollback limits

Fri, 11 Sep 2026 05:00:00 +0800

Automatic rollback for a failed deployment is not docker compose down after the script dies. Recovery depends on three facts: whether the candidate already took public traffic, whether the previous upstream can still be restored, and whether business checks finished. If the previous version is still serving, stop only this candidate. If the traffic switch may be half-done, restore the previous upstream. If the new version is still in the observation window, switch back. Recovery should finish the commit records only when the release has already entered the commit phase.

Docker Compose Blue-Green: Health Check, Switch, Drain

Fri, 11 Sep 2026 05:00:00 +0800

A Docker Compose blue-green deployment on one server starts the candidate, waits until the app is ready, validates and switches the Caddy upstream, proves the public hostname, drains old connections, then stops the old version. Do not delete the old container before the candidate is taking traffic.

That sequence can shrink the unavailable window. The host, disk, Docker daemon, and shared database are still single points of failure, so measure the window instead of calling the result zero downtime.

The gateway switch is the only public cutover. Candidate startup and warmup happen before that switch.

Docker Compose blue-green only works under these constraints

Run two app instances on one host only when the service meets all of these conditions:

Hosted Checkout vs Embedded Checkout

Fri, 11 Sep 2026 05:00:00 +0800

RouteNest put the Pro payment form on the pricing page. A Dutch buyer chose iDEAL, and the browser still left for the bank. After the buyer authorized and came back, membership did not turn on, because the payment webhook had not arrived. Nothing was broken: where the form lives, whether the payment leaves the page, and whether payment is confirmed are three different jobs.

If the provider’s full checkout page already covers the required payment methods and fields, start with hosted checkout. Keep a hosted embedded form only when the product configuration before payment cannot be abandoned. Split into hosted components when a prebuilt form cannot hold seats, add-ons, or a live quote. Generating the card number field in your own page jumps the security and compliance work; that is usually the wrong starting point for SaaS.

Merchant of Record vs Payment Processor: Who Sells the Order

Fri, 11 Sep 2026 05:00:00 +0800

A customer buys a pretax $100 SaaS annual subscription and pays $20 more in tax. Both setups can mark the order paid. Direct payment processing still has your company selling to the customer and carrying tax, refunds, and delivery. A merchant of record (MoR) becomes the seller the buyer faces on in-scope orders, then pays you a supplier amount after tax, fees, and contract adjustments.

That is the merchant of record vs payment processor difference that matters. A payment processor answers how authorization, capture, and settlement complete. An MoR also changes who sold the product to the buyer. Hosted versus embedded checkout, whose API you call, and which balance first held the funds cannot prove seller identity on their own.

Why Pin a Docker Image Digest: Reproducible Deploys and Rollbacks

Fri, 11 Sep 2026 05:00:00 +0800

Pin a Docker image digest by writing the production image as repository:tag@sha256:digest. The version tag shows which release you planned. The digest is the content Docker must pull. latest, stable, or a movable version tag cannot guarantee that a rebuild or rollback returns the original image.

Pinning the index digest freezes the platform set. Each node still pulls the manifest that matches its architecture.

Why pin a Docker image digest instead of a moving tag

Docker’s image digest documentation(opens in a new tab) defines a digest as a SHA-256 identifier of image content. A registry maintainer can retarget the same tag to a patched image. The original digest does not move with the tag.

How to Use Claude Code Hooks: Deterministic Checks

Fri, 11 Sep 2026 04:48:00 +0800

How to use Claude Code hooks is not about memorizing every event. It is about whether the action has a clear trigger and a unique result. A project config check belongs in a hook: after the file is written, run the same command. Valid config exits success. Invalid config returns a determined error. The model does not choose the standard.

Project rules name the config path and the fixed command. The prompt describes this change. A skill handles live judgment. The hook only calls the project command on a matching event. Claude Code and Codex keep their own event config and share the same check.

How to Write Claude Code Skills: Repeatable Workflows

Fri, 11 Sep 2026 04:40:00 +0800

How to write Claude Code skills depends on whether the flow repeats across tasks, whether it still needs on-the-spot judgment, and whether the project can observe a result after it runs. Facts that stay true in a repository belong in project rules. A one-off requirement belongs in the current task prompt. Actions that must run on an event belong in a hook. External services and data come from MCP or other tools.

A full-stack project that often changes an existing API contract has to find the real producer, confirm approved field meanings, sync direct consumers, run existing checks, and observe a page or a call. The fields and the range change every time. The judgment order stays stable. That flow belongs in a project skill. The field names, paths, and acceptance result for this run still come from the current prompt.

OneDev Tutorial: Docker Compose, Git, and CI/CD on One Server

Fri, 11 Sep 2026 04:24:00 +0800

A OneDev tutorial starts with one instance that can host Git, review, issues, CI/CD, artifacts, and packages. Keep code on a server you operate, and skip running a separate Git service, CI, and package registry, when that trade-off is worth the ops work. The official single-node baseline is also lower than full GitLab.

The environment is one 64-bit Linux host: OneDev and PostgreSQL run under Docker Compose, and Caddy terminates HTTPS. After the instance is ready, create a Go project and prove push, tests, image build, production deploy, backup, restore, and upgrade. A container in running is not enough. The repository, Git SSH, the pipeline, and restore still have to work.

Migrate a Website to a New Domain: 301, 308, Canonical

Fri, 11 Sep 2026 04:22:00 +0800

When you migrate a website to a new domain, each live old URL should take one permanent hop to the matching new URL, including the path and any query string that still belongs to the page. Canonical tags, internal links, sitemaps, structured data, and analytics on the new host must already name the new domain.

Home, article, topic, and asset each keep their path on the new host.

Build a one-to-one URL map before the cutover

Export old URLs from the sitemap, access logs, Search Console, backlinks, and the database. Then give each address one destination:

Cache-Control for Static Assets: ETag and Fingerprints

Fri, 11 Sep 2026 04:20:00 +0800

Cache-Control for static assets cannot be one header copied onto every path. Fingerprinted CSS, JavaScript, and fonts can stay cached for a year. HTML has to revalidate so it can pick up new URLs. Images that keep the same filename can stay cached only for as long as outdated bytes are acceptable. Responses that carry account or payment data must not enter a shared cache.

Cache lifetime follows whether the URL changes with the content, whether the response is public, and how long stale copies are allowed to remain.

Cache-Control for static assets starts from whether the URL changes

Resource	When the URL changes	Usual policy	Publish requirement
HTML	The address stays; the document changes	`no-cache` or a short `max-age`	Revalidate or expire in time for the next release
Fingerprinted CSS, JS, and fonts	The filename changes with the bytes	`public, max-age=31536000, immutable`	HTML must reference the new URL
Unversioned images and PDFs	The same address may be overwritten	Short cache plus ETag	Purge that URL or change the URL after a replace
Public API responses	Business semantics decide	Explicit `public` or `private`, `s-maxage`, and `Vary`	The cache key must cover every response difference
Sensitive or one-time responses	Reuse is not allowed	`no-store`	The CDN must not cache them either

app.4f81c9a2.js can be treated as immutable only because a content change produces a new filename. A directory named /assets/ does not prove that every file inside it is immutable.

How to Model SaaS Products, Plans, and Prices

Fri, 11 Sep 2026 04:18:00 +0800

RouteNest is about to raise Pro monthly from $19 to $24. If the system stores one mutable row—plan=pro, price=19, stripe_price_id=...—writing 24 over 19 removes the basis for existing subscriptions. Whether the $190 annual price moves, whether the euro price is recomputed, which amount WELCOME20 discounts, and which Paddle or Creem object to charge all become guesses.

How to model SaaS products and prices depends on when each fact changes. Product says what is sold. Plan says which features and limits the buyer receives. Price says amount, currency, interval, and version. A promotion only changes a qualifying sale. A provider mapping only projects an internal Price onto a payment channel. Orders and subscriptions must store the snapshot from the sale; they cannot reread “the current price” to explain the past.

Why a Payment Processor Application Gets Rejected, and How to Resubmit Evidence

Fri, 11 Sep 2026 04:16:00 +0800

A payment processor application is rejected when a reviewer cannot independently match who is selling, through which domain, what the buyer receives after payment, who handles cancellation or refunds, and who receives the net proceeds. Genuine files still fail when those facts point at different businesses.

The application names Northstar Labs, Inc.. The site footer only shows the product name RouteNest. The pricing page sells a USD 19 monthly auto-renewing subscription, while the refund page still describes a one-time download. The product is behind login and the reviewer has no account. The payout account still names the founder personally. Each of those statements can be true. Together they do not say who sells what, how it is delivered, or where the money goes.

How to Expose Docker Ports: 127.0.0.1, 0.0.0.0, Firewalls

Fri, 11 Sep 2026 04:14:00 +0800

How to expose Docker ports depends on the process listen address inside the container, the host publish bind, and the firewall or cloud security group in front of the host. Listening on 0.0.0.0 inside a container does not put that port on the public internet.

The app and database stay on the Docker network. The public internet reaches only the ports the proxy publishes.

How to expose Docker ports at each network layer

Where it is set	Example	What it means
App process listen	`0.0.0.0:8080`	Accept 8080 on every interface in this container
App process listen	`127.0.0.1:8080`	Accept 8080 only on this container’s loopback
Docker port publish	`127.0.0.1:8080:8080`	Host-local processes can reach container 8080 on host 8080
Docker port publish	`0.0.0.0:8080:8080`	Every IPv4 address on the host publishes 8080; the public internet may reach it
Compose internal access	`http://app:8080`	A peer on the same network uses the service name and the container port

The two uses of 0.0.0.0 are not the same action. Listening on every interface inside the container lets a proxy on the same Docker network connect. Publishing the port onto every host interface widens the host entry.

DNS Record Types: A, AAAA, CNAME, TXT, and CAA

Fri, 11 Sep 2026 04:12:00 +0800

DNS record types A, AAAA, CNAME, TXT, and CAA store different answers. A and AAAA hold the server address. CNAME holds another name so a CDN or host can keep the later addresses. TXT holds ownership proofs and mail policy. CAA names which certificate authorities may issue.

When the hostname should reach a server you control, publish A or AAAA. When the platform issues a hostname instead of a stable IP, publish CNAME. TXT and CAA do not send traffic; they only constrain verification and issuance.

A, AAAA, and CNAME decide where traffic goes. TXT and CAA store verification, policy, or certificate limits.

How DNS record types A, AAAA, CNAME, TXT, and CAA differ

Record	Value	Common job	Usual failure
A	IPv4 address	Point a name at an IPv4 server	The server IP changed and the record did not
AAAA	IPv6 address	Point a name at an IPv6 server	IPv6-capable networks try an address the service cannot serve
CNAME	Another name	CDN, hosted platform, object storage	The same owner also has A, TXT, or MX
TXT	A text string	Domain ownership, SPF, DKIM, DMARC	The console appended the zone, or the copied value gained a space
CAA	A CA identifier	Limit which issuers may mint certificates	The CA already in use is missing, so renewal fails

Consoles label the DNS name as Host, Name, or Record name. Each record still has a name, a type, a value, and a TTL. Google Cloud DNS records overview(opens in a new tab) lists common uses. A and CNAME semantics are in RFC 1034(opens in a new tab). AAAA is RFC 3596(opens in a new tab). CAA is RFC 8659(opens in a new tab).

How to Write Claude Code Prompts: Current Task Only

Fri, 11 Sep 2026 04:10:00 +0800

How to write Claude Code prompts depends on what this task still lacks after project configuration. Project rules already hold the repo map, commands, and long-lived boundaries. Skills already hold repeatable workflows. Hooks and CI run deterministic actions. Permission policy limits tools. The current prompt only needs the state to change, the evidence you already have, the affected range, the authorization boundary, and the result that must appear when the work is done.

The prompt does not need YAML, XML, or a fixed form. A local defect can be short. Context that crosses several owners is added only when that context changes the result. The test is not word count or field count. It is whether the agent can start from the current project, make the change inside authorization, and confirm the software reached the target state.

When to Run Database Migrations: Expand, Migrate, Contract

Fri, 11 Sep 2026 04:10:00 +0800

When to run database migrations depends on whether the current schema can serve both the old and the new application. Add compatible structure first, ship the new app, then backfill data. Drop columns, finish renames, and tighten constraints in a later release after the old version has left.

Destructive DDL is not tied to the first rollout of new code.

When to run database migrations depends on compatibility

The same DDL can wait on a lock for seconds or for minutes depending on table size, PostgreSQL major version, and live writes. Confirm those facts, plus how old and new code touch the table, before choosing a stage.

How to Write AGENTS.md: Root vs Directory Rules

Fri, 11 Sep 2026 03:20:00 +0800

How to write AGENTS.md starts with who a fact stays true for, and whether it should change a coding agent’s next file or command. Repo-wide maps, canonical commands, and cross-module boundaries belong at the repository root. Rules that only bind backend, frontend, or a worker sit in that directory. Habits that hold across repositories stay in the user-global file. What this task must change stays in the current prompt. CLAUDE.md uses the same content boundary; Claude Code just finds it through its own files.

If the root file also stores frontend commands, backend migrations, a release workflow, and “do not touch deploy this time,” four different lifetimes enter unrelated sessions. Confirm the fact in code or build config first, then keep the long-lived rule in the smallest scope that still needs it. Workflows, task variables, and hard stops belong to other mechanisms. The same scope-and-mechanism split is already mapped in Claude Code configuration.

Claude Code Configuration: Global vs Project

Fri, 11 Sep 2026 02:00:00 +0800

Claude Code configuration has to answer two questions: who should see this fact, and how it should take effect. Habits that hold across repositories belong at the user layer. Facts the team shares belong in the repo. Rules that only bind frontend or backend sit next to that directory. This change stays in the prompt. A repeatable judgment workflow becomes a skill. A mechanical action that must run is a hook, a permission, or existing CI.

The split does not require a separate config repository or a new directory template. It starts from the repo already in use and moves facts out of chat logs, global files, and duplicated project rules until each fact has one source of truth. Claude Code and Codex can share that source. Each client still owns its file format, discovery order, and events.

About StackOnward

Mon, 01 Jan 0001 00:00:00 +0000

StackOnward follows a software product from idea through development, launch, and operations.

Focus

Product and engineering: product design, architecture, frontend, backend, data, and AI.
Payments and subscriptions: pricing, checkout, payments, subscriptions, entitlements, and finance.
Websites and growth: site delivery, performance, SEO, content, social, ads, and sales.
Operations and automation: servers, containers, monitoring, releases, workflows, and scripts.

Browse

Articles: all articles by date.
Topics: browse by domain.
Series: read in order.
Resources: scripts, templates, workflows, and examples.

Contact

Technical questions, editorial collaboration, and project consulting:

GitHub(opens in a new tab) · E-Mail · · X(opens in a new tab) · RSS