# Doggo Pokko review and maintenance SOP

This SOP describes the current stateless review service. It does not authorize new paid APIs, owner-data collection, messages, bookings, provider integrations or directory submission. Archived research refresh SOPs remain research artifacts.

## Reproduce the review

1. Use Node 22 or newer in the source repository. `npm ci --ignore-scripts`; `npm test`; `npm start`. Local URL is http://127.0.0.1:18183. No credentials/database needed.
2. Run `npm run verify:mcp -- http://127.0.0.1:18183`. The official client verifies legacy initialize and modern protocol discovery, five data tools plus the native-UI opener in the candidate, seven workflows and malformed-input rejection. Candidate HTTP/MCP and independent browser checks are under deploy/; run them from the repo root with the recorded environment. Install/use Chromium for browser checks.
3. Inspect seven synthetic website flows, missing/negative amounts, reported emergency/pain overrides, consent and text-confirmation gates, local photo preview request trace, source joins, mobile layout and reduced motion. Test code and receipts are engineering evidence, never real owner or clinical validation.
4. Verify private paths remain denied: .env/.git, server source/dependencies, docs/work, deploy logs and archived ops/inputs. Public documents are an exact allowlist under docs/public; arbitrary docs paths are not served.
5. For the live endpoint use `npm run verify:mcp -- https://doggopokko.sandboxmcp.app`, with normal TLS verification. Verify actual app/revision in /health and inspect outputs; HTTP200 alone is insufficient.
6. Validate the portable package using `npm run validate:plugin`. Build with `npm run package:plugin` only after a fresh successful public official-client receipt. Inspect archive members, single contained folder, manifest/MCP schemas, skill and branding. No secrets, dependency caches, symlinks or operational logs belong in the package. Downloading does not install an account plugin.

## Maintain evidence and provider pointers

- Keep stable evidence IDs, canonical URLs, inspected-content/access labels, geography, inspection/publication dates, limits and exclusions. Preserve original observations rather than rewriting anecdotes as clinical or statistical facts.
- Source guidance from primary professional/operator pages and review material changes. Label page marketing as a provider claim. Never infer credentials, available slots, full quotes or partnerships from a listing.
- The current provider display uses one curated Bengaluru grooming pointer. Seven-day display freshness is a product policy, not verification that a price remains valid. Stale/invalid/future dates yield null. Keep unknown values unknown.
- Changes to provider records require actual public inspection and source provenance. Partner APIs, licences, verified qualifications, inclusive quotes and slots remain future work with their own access/terms/validation requirements.
- Changes to clinical-facing wording require qualified professional review before claiming reviewed status. Current cards say professional_review:pending. No portrait-based diagnosis, medication, temperament or individual diet conclusion is permitted.

## Release and rollback boundary

The repository's deploy/ instructions describe the trusted operator process. Runtime belongs only to owned /opt/doggopokko releases and its service, with a loopback upstream and exact hostname. Existing HostingX/Etracket services, containers, databases and route semantics must be preserved. Deployment secrets remain private inputs to the established helper; no .env/helper credentials go in source, logs, screenshots, archives or public files.

A release needs tested concrete source, a pinned revision, safe allowlisted archive, validated proxy candidate, protected pre/post health/identity checks and owned rollback. Verify public SSL/pages/docs/graph/demo/MCP/presentation and downloadable byte hashes, then record the deployed revision. A provisional working snapshot is labelled as such and is not a committed revision. Root owns the authored presentation/exports and final commit/push in this build.

Use recorded owned rollback state and guards; refuse stale pointers or concurrent proxy changes. Recheck protected services and restore the current review release after a rehearsal. Do not blindly overwrite unrelated proxy config or operate the inactive standard Caddy service. DNS already resolved the correct ingress during this review; this does not authorize other DNS changes.

## Report limitations honestly

Separate current implementation, actual public verification, archived prototype checks and future work. A successful tool call, synthetic replay, agent review or source inspection cannot establish owner usability, clinical performance, measured prevalence, willingness to pay, unique market opportunity, provider quality or a ChatGPT-installed status. Exact remaining dependencies belong in the durable deployment/build status rather than a fabricated success claim.

## Native UI candidate review

Run `node deploy/verify-local-public.mjs` for all owned public routes, private-route denial, downloads and native MCP checks against an isolated local server. Run `node deploy/verify-chat-ui.mjs --local` for an isolated local HTTP/MCP server (no credentials). Run `node deploy/verify-chat-ui-browser.mjs --local` for independent Chromium contexts and the real widget inside a synthetic MCP Apps host bridge. Use `CHROMIUM_PATH` if Chromium is not `/usr/bin/chromium`. Receipts and screenshots stay in ignored `.cache/chat-ui/`. These are synthetic bridge checks, never actual ChatGPT-host acceptance.

For public candidate verification after root activation: `node deploy/verify-chat-ui.mjs https://doggopokko.sandboxmcp.app EXACT_COMMIT_SHA`. Before activation the old public release can be checked using `--baseline`; that mode verifies its five data tools and records UI route statuses without claiming native readiness. Do not accept baseline mode as candidate release evidence. Root must also run the full public route/download verifier and infrastructure comparison using a pinned source revision.

Review all seven workflows at 390 px in light/dark mode, keyboard focus, overflow, consent/description confirmation, local-only photo/reset/revocation, incomplete costs, reported urgent/pain branches and host tool-input/result/error/stale handling. Confirm no persistence or provider contact. After registration, test the real ChatGPT host on desktop and mobile separately; no browser harness can substitute for this.

The operator's new activation receipts are `.cache/chat-ui/release-receipt.json`, with related release/public/MCP/infrastructure receipts there. Registration in ChatGPT Plugins and the real `.app.json` binding belong to root; a downloadable skill package alone does not register an MCP connection. Resource URI versioning is required when a released widget changes incompatibly.