v0.12.0 — deploy to Google Cloud from your own cost estimate

Deploy to Google Cloud from your own cost estimate, with every secret in Secret Manager.

• New /pspt:deploy-gcloud (skill). It installs the Google Cloud CLI if missing, signs in, and asks for the environments (staging only, or staging and production), each with its project and region.
• The architecture is your Pricing Calculator estimate: export it as CSV and give the path or paste it. Each line item becomes a resource: single VM, Cloud Run, VM groups, GKE Autopilot, App Engine flexible, Cloud SQL, load balancer, buckets. The skill shows back the shape, a diagram, the total and what the estimate leaves out, then asks only what is still open.
• Secrets move from .env.secret into Secret Manager without passing through the conversation. CI/CD is GitHub Actions through Workload Identity Federation (no key files, no GitHub secrets) or Cloud Build. Staging ships on push to main; production ships on a v* tag, behind a reviewer.
• One plan, approved once, before anything billable is created. The skill never pushes, never tags and never deploys production itself.

---

Full history: CHANGELOG.md

v0.11.0 — test what you touch; the whole suite at the boundaries

Test what you touch while building; run the whole suite at the boundaries.

• New references/test-cadence.md: three tiers. Each criterion or ticket task runs only the tests of the code in hand (plus pnpm check, which is static). Each ticket phase runs its own T rows and the R rows of the files it edited. The whole suite runs once at a boundary: the last criterion of a phases.md phase, a ticket's close-out, and before any push.
• /pspt:build, /pspt:build-long, /pspt:ticket and /pspt:ticket-build follow it: no more full runs per criterion or per phase.
• Resource discipline so the suite fits an ordinary laptop: one database container per test run (Vitest globalSetup and a migrated template database, one copy per file) instead of one per file, unit and integration as separate projects, capped maxWorkers, and no browser or dev server left running between steps.

---

Full history: CHANGELOG.md

v0.10.0 — landing scaffold in the spec; the build codes one section folder at a time

Landing pages get a plain scaffold, and the build codes one section folder at a time.

• /pspt:landing-spec gains L4 Scaffold: a plain landing/ folder from templates — index.html, a ten-line Vite inliner, shared/ (tokens, base, a small page.js with stitch, SEAM and handoff) and one sections/NN-name/ folder per section with its own index.html, style.css and script.js.
• /pspt:landing-build now codes one section per run straight into that section's folder. No React, no TypeScript, no tests, no toolchain; each section is checked by eye in the browser, desktop and phone, with its seams at 85/55/25%.

---

Full history: CHANGELOG.md

v0.9.1 — every landing section proven full screen

Every landing section is proven full screen.

• Content longer than one screen becomes a pinned stage or more scenes; only pinned and track scenes may be taller, inside the pin budget.
• /pspt:landing-build adds scenes.spec.ts: with motion on, on desktop and phone, every section is at least one viewport tall and its [data-stage] does not overflow.

---

Full history: CHANGELOG.md

v0.9.0 — landing pages, specified then built scene by scene

Landing pages — specify the story, then build it scene by scene — and an S3 architecture, security and reliability review.

• Add /pspt:landing-spec: from the BRD, PRD and mockup — or, without them, from an interview that asks what website to build, defines the requirements that kind of site needs and stops while information is lacking — write the landing page's creative rules (colour as families, never flat values), its story spine and seam map, and one document per section, with a seam gate that fails when neighbouring sections do not join. Companion craft skills (GSAP, scroll storytelling, SVG, impeccable, frontend-design, motion-framer) are listed and read when a stage needs them.
• Add /pspt:landing-build: implement docs/landing/ as a full-screen, scroll-told React + TypeScript page with GSAP's whole plugin set, SVG and Framer Motion — one phase per run (motion foundation, each section joined to the one above, hardening, whole-page review), tests first, every seam proven by a screenshot audit and an e2e seam test. References for each technique are searched live at build time.
• Add S3 for system architecture, security and reliability decisions, with requirement-backed dispositions and observable proof.
• Move technology selection to S4 and downstream stages through S9; normalize legacy state without resetting completed build criteria.
• Carry architecture decisions into backend job contracts, frontend failure states and phase exit criteria.

---

Full history: CHANGELOG.md

v0.8.3 — readable formatting, validated phase planning and Docker test cleanup

Readable formatting, frontend validation before phases, and disposable Docker test storage.

• Formatting adds consistent blank lines between imports, functions and control flow while preserving the canonical linter checks.
• Specification stages now run S6 mockup fidelity, S7 UI gaps and frontend validation, then S8 phase planning. Legacy stage records retain their completion dates.
• Docker test workflows avoid persistent volumes, remove owned disposable resources on teardown, and verify that tests leave no containers or volumes behind. Existing project data is preserved.

---

Full history: CHANGELOG.md

v0.8.2 — commit only inside a git repository

Commit only inside a git repository. Tickets, smoke tests and the
helper-tool setup now work on a plain folder that holds two clones — the folder
the tutorial recommends for an existing project — instead of failing at the
first commit.

Fixed

• On a folder that is not a git repository (my-app/ holding backend/ and
  frontend/ clones), /pspt:ticket could not commit the helper-tool files
  (.mcp.json, .claude/, CLAUDE.md, AGENTS.md, .agents/), and none of
  its parent commits — the plan, the approval, each phase, the close-out — had
  anywhere to go. Found by running the real skills on such a folder.

Changed

• One rule, conventions §11:
  a commit is made in each git repository the work touched, and nowhere else.
  A package that is a repository gets its own commit. A parent that is not a
  repository gets none — tickets/, docs/, the tooling files and
  .pspt-smoke/ stay on disk, and the report says so once. No skill runs
  git init.
• A parent that is a repository commits only its own files. backend/ and
  frontend/ are staged into it only when .gitmodules registers them as
  submodules; two plain clones are left to their own repositories.
• A Committed — <sha> box in a ticket reads n/a — not a git repository when
  no repository owns that phase's files. A skipped commit never blocks a step.
• Applies to /pspt:ticket, /pspt:ticket-build, /pspt:fix-flow,
  /pspt:fix-flow-proceed, /pspt:smoke and the tool setup
  (references/prerequisites.md §3.5). /pspt:smoke adds .pspt-smoke/ to
  .git/info/exclude only where there is a repository to exclude it from.

---

Full history: CHANGELOG.md

v0.8.1 — smoke test: look at the data, then ask how to seed and who to log in as

Smoke test: look at the data, then ask how to seed and who to log in as.
/pspt:smoke now checks the local database before it visits any page.

Added

• Data and accounts step — before any visit, /pspt:smoke confirms the
  database is local (otherwise it stops), counts the rows in the tables the
  chosen pages read and the users per role, finds the project's own seed and
  reads whether it deletes data first, and works out which roles the pages
  need. Then it asks two questions:
  • Data: use what is already there · run the project's seed (saying what
    it deletes first) · generate a smoke seed — the fewest rows the pages need,
    built from data-spec.md, every row marked and removed again in clean-up
    · or "I'll seed it myself".
  • Accounts: one throwaway test user per role · the seed's accounts · or
    the user's own account, for this run only and never printed.
• Named logins in smoke.mjs — "logins": { "customer": …, "admin": … }
  opens one browser session per account; each target's auth names the
  account it visits as.

Changed

• Clean-up also removes generated seed rows (children first, by recorded id)
  and deletes a run plan that holds a password the user typed. Rows from the
  project's own seed stay, and the report says so.
• A role the API cannot grant is created through the app's own user service,
  or inserted with a password hashed by the app's own function — never plain
  text.

---

Full history: CHANGELOG.md

v0.8.0 — smoke test: open the app in a real browser and look

Smoke test — open the app in a real browser and look. One new skill answers
"does the app run": it asks what to check, asks before it starts Docker and
Chrome, visits each page once and saves a picture of every one.

Added

• /pspt:smoke — offers the pages to check from the frontend router, the
  spec's screens and local HTML files (email previews), then asks once for
  permission to run Docker and Chrome for this run. It uses the app if it is
  already running, otherwise docker compose up -d --wait; logs in with a
  throwaway smoke+<time>@example.test user when a page needs it; visits each
  page once; and saves a full-page PNG of each. A page fails on an HTTP error,
  an uncaught JavaScript error, a failing or 5xx request to the app's API, a
  console error, a missing element or a login redirect — and the assistant
  reads every picture, so a blank page or a broken layout fails too. The test
  user is always deleted, and only what the skill started is stopped.
• references/smoke/smoke.mjs — the runner: Playwright from the project
  first, then a global install; Google Chrome first, then Playwright's
  Chromium. Writes the PNGs and report.json to .pspt-smoke/<run>/, which is
  excluded from git. Exit 0 pass, 1 fail, 2 no browser.

Limits, stated in every report

• Local only: never production or staging, never a migration outside the local
  container, never a deploy, never a real email or payment.
• Desktop Chrome only — not how Gmail or Outlook render an email, no
  email-client dark mode, no WebP handling of mail clients.
• One visit per page — a smoke test, not a test suite. Failures are offered as
  a /pspt:ticket; the skill never edits code.

---

Full history: CHANGELOG.md

v0.7.0 — fix the toolchain, then fix the code: until everything is green

Fix the toolchain, then fix the code — until everything is green. Two new
skills repair an existing project, JavaScript projects get their own
toolchains, disables become reported instead of banned, and every skill now
brings the tools it needs.

Added

• /pspt:fix-flow — finds each package, detects its stack (Express,
  NestJS, React, Next.js) and language from its dependencies and sources, and
  compares its toolchain with pspt's. A match prints "nothing to fix";
  otherwise it installs pspt's files, removes second configs, pins versions and
  scripts, drops only unused lint/format/hook packages, installs, autofixes and
  reports what is left. Unsupported stacks are refused with the reason. Its
  mechanics are references/toolchain/fix-flow.mjs.
• /pspt:fix-flow-proceed — loops over the code until check and the test
  suite pass: failing tests first (the safety net), then types, lint and knip,
  one file per iteration, behaviour unchanged, asking instead of guessing.
  Commits land through the hooks once the tree is green. Its work queue is
  references/toolchain/findings.mjs.
• JavaScript toolchains — express-js, react-js, nextjs-js: the same
  rules minus the TypeScript-only ones, Node or browser globals, Jest/Vitest
  globals for tests. All seven stacks pass verify/.
• Required tools for every skill (prerequisites.md)
  — jCodeMunch and
  Ponytail. Missing → one question, then the skill
  installs them itself and registers them for the project: .mcp.json,
  .claude/settings.json, CLAUDE.md, AGENTS.md, .agents/rules/.
  pspt's spec, conventions, lint rules and tests always win over Ponytail.
• Re-index after every phase — jcodemunch re-indexes only the files each
  phase, criterion, iteration or ticket changed.

Changed

• Disable directives — allowed, never silent (conventions §10): the rule
  named and a reason after --, enforced in every config; blanket, unpaired
  and unused disables are errors; @ts-expect-error only with a description.
  They never block a skill and are always reported — progress line, report,
  disables: commit trailer, and findings.mjs.
• Toolchain scripts and hooks work with npm, pnpm or yarn.

Fixed

• Shipped toolchain files were not Prettier-formatted, so the first
  prettier --write made every project read as drifted.
• JavaScript configs linted pspt's own eslint.config.mjs, which failed its
  own rules; all configs now ignore pspt's toolchain files.

---

Full history: CHANGELOG.md