browser-verification-stand

Verifies web applications on production builds served behind real proxies and stands.

1|Updated Jan 14, 2024
One-click install
npx skills add https://github.com/Eyhenij/rt-tools --skill browser-verification-stand-eyhenij
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: browser-verification-stand
Source: https://github.com/Eyhenij/rt-tools/tree/main/.claude/skills/browser-verification-stand
Command: npx skills add https://github.com/Eyhenij/rt-tools --skill browser-verification-stand-eyhenij

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Dev servers hide or alter server-side markup, locales, caches, redirects, and headers, so conclusions drawn from them are unreliable. This Skill defines how to raise honest verification stands — production builds of the site, admin, and API, optionally behind real nginx — so every claim about behavior is backed by a measurement on the real artifact. ## Core Features & Use Cases - Production-build verification: Build and serve the site, admin, and API as compiled artifacts on dedicated stand ports, with port-state checks via lsof before the first request. - Real nginx stand: Run the tree's actual deploy/nginx.conf in Docker to draw valid conclusions about 301 redirects, Cache-Control, and X-Cache-Status. - Admin sign-in workflow: Sign in through the real form with the seeded local account, handling classifier refusals by requesting normal mode rather than bypassing the live sign-in path. - Baseline comparison: Use git worktree to raise a second tree's stand on separate ports so "before vs. after the edit" claims are measured, not remembered. - Use Case: After editing a redirect rule, build the site, raise the nginx stand in Docker, and confirm the 301 and cache headers with curl against the real proxy config. ## Quick Start Ask the agent to verify the edit on a production build of the site served behind the real nginx stand and report the measured response headers.

Frequently Asked Questions about browser-verification-stand

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a web app on a production build instead of a dev server?

Build the artifact (for example `npx nx build site`), then launch the built server on a dedicated stand port and measure responses with curl. Dev servers alter or omit server-side markup, locales, caches, and headers, so conclusions must come from the built output.

How do I test nginx redirects and cache headers locally?

Run nginx in Docker with the repository's real config mounted as a directory, publishing the proxy ports and mounting the built static assets. Only this stand yields valid conclusions about 301 redirects, Cache-Control, and X-Cache-Status, since those rules live in the nginx config, not the application.

Why does a static server return 404 for my single-page application routes?

A static server knows nothing about SPA routes and does not fall back to the entry point on deep links, and the app also calls procedures on its own origin. Serve the build through the tree's real proxy config instead, which both serves the files and proxies the API calls.

Why does a port answer 200 with old code after a rebuild?

A built artifact from a past session is still listening on the port and answers with stale code. Find every such process with `lsof -nP -iTCP:<port> -sTCP:LISTEN` and kill each by PID before measuring.

When should I not use a dev server for verification?

Never use it as confirmation: server-side markup, locales, caches, redirects, and headers differ or are absent on dev servers. It is only fit for orienting yourself on an unfamiliar screen; confirmation requires a measurement on a production-build stand.