Pstack

chmonitor pstack validation

This is a project-local adapter to the pstack method from michael-denyer/pstack-claude. The adapter adds chmonitor's CI-first validation contract and feature map; it also has a pinned, supplemental copy of the upstream skills-only tree at upstream/. The source, loading boundary, and provenance are documented in README.md and upstream/SOURCE.md. The maintained feature map starts at features/README.md, and the inventory and CI matrix are in docs/knowledge/pstack-validation.md.

Use this skill as the project rule for validation. The default proof is the CI run for the commit under review. Do not infer that a change works because a local file parses, a build used to pass, or a proxy reports a cached result.

Operating rules

• CI owns dependency installation, lint, type checks, unit tests, builds, browser test setup, Rust builds, Helm rendering, and deployment checks.
• Do not start a local app, install a QA toolchain, or run a heavy pnpm, bun, cargo, helm, docker, or browser command by default. Use the matching workflow and capture its job result instead.
• Use stable user entry points and observable state. Do not use internal setters, a different route, or a mocked response as a substitute for the mapped feature.
• A missing path-filtered job is not a pass. Record the exact workflow, trigger, and prerequisite that were absent.
• Use verified, verified-unreachable, or blocked as the result. Never silently turn a skipped or non-required check into verified.
• Keep credentials, cookies, API keys, passwords, private webhook URLs, and full response bodies containing them out of commands, logs, and evidence.
• The parent OpenCode runtime owns the model choice. This skill does not override the configured model or add Claude-only slash commands.

UI and mode contracts

Use the product-design and cloud-saas-mode skills as the expected-state reference while reviewing CI evidence. In particular, a dashboard proof should respect the existing semantic-token and shadcn boundary, the ?host=N route contract, hooks at the deepest consumer, the shared loading/empty/error states, and the stale-data behavior. Do not “fix” a UI proof by editing components/ui/ or by creating a new visual primitive in this skill.

For cloud and auth claims, keep OSS and Cloud behavior distinct. Public demo visibility, hidden demo data for signed-in users, per-user connection isolation, and anonymous guest-agent exceptions are contracts to test, not alternate interpretations of a failed response.

For dashboard UI expectations, read the sibling product-design skill. For cloud, auth, and per-user connection boundaries, read cloud-saas-mode. The older verify-chmonitor skill is still the detailed local CLI/TUI recipe. Use it only for a requested CLI proof, not as a substitute for the CI matrix.

Launch

For a pull request, launch means identifying the CI run for the exact commit. Start with file inspection and the checks API:

git status --short --branch
git diff --name-only origin/main...HEAD
gh pr checks <PR> --watch=false

Map changed paths to the workflows in the feature file. A deployment change can be path-filtered, so also inspect the run's job list before deciding that a surface was not exercised.

For a post-deploy smoke proof, use the existing dashboard harness from its package directory. The unauthenticated form needs no secret:

cd apps/dashboard
bun scripts/verify-deploy.ts --skip-auth

The Cloudflare workflow supplies CHM_API_KEY_SECRET only inside CI and calls the same script for its authenticated deployment check. Do not copy that variable into a local shell, a commit, or a transcript.

A CLI proof has a different launch model. The existing helper builds this checkout's Rust binary, so it is optional and heavier than the CI path:

.cursor/skills/verify-chmonitor/scripts/launch.sh

Do not run the helper merely to validate documentation. The Rust workflow owns the normal build and test proof.

Doctor

Run a read-only identity and scope check before interpreting a result:

git status --short --branch
git diff --check
gh pr checks <PR> --watch=false

For an approved live deployment, distinguish the three health contracts before making a claim:

• GET /healthz is the static process liveness endpoint.
• GET /api/health is the minimal public deployment health response.
• GET /api/healthz is ClickHouse-gated readiness and may return 503 while the monitored database is unavailable.

Use the current workflow URL and the existing verify-deploy.ts rather than inventing a request or copying a secret-bearing curl. For the CLI, the identity-only doctor helper is .cursor/skills/verify-chmonitor/scripts/doctor.sh; it does not contact the hosted dashboard by default. A failed connectivity row after an identity pass is a separate observation, not proof of a wrong binary.