@silverassist/agents-toolkit 2.3.0 → 2.5.0

package/templates/shared/prompts/create-github-pr.prompt.md

@@ -0,0 +1,147 @@
+---
+agent: agent
+description: Create a pull request for the current branch linked to a GitHub issue
+---
+
+# Create GitHub Pull Request
+
+Create a pull request for the current branch linked to GitHub issue **#{issue-number}**.
+
+## Prerequisites
+- Run `prepare-pr` first to ensure code is ready
+- GitHub MCP connection or `gh` CLI required
+- Reference: `.github/prompts/_partials/pr-template.md`
+- Reference: `.github/prompts/_partials/git-operations.md`
+- Reference: `.github/prompts/_partials/github-integration.md`
+
+## Steps
+
+### 1. Verify Current State
+
+```bash
+git branch --show-current
+git status
+```
+
+Verify:
+- Branch follows convention: `feature/{issue-number}-*` or `bugfix/{issue-number}-*`
+- All changes are committed
+- Not on protected branch
+
+### 2. Review Changes
+
+```bash
+BASE_BRANCH=$(node -e "try{const c=require('./.agents-toolkit.json');console.log(c.pr?.targetBranch||c.git?.defaultBranch||'main')}catch{console.log('main')}")
+git diff "$BASE_BRANCH" --name-only
+```
+
+- Reuse `BASE_BRANCH` in all subsequent steps
+- Summarize the changes made
+- Identify breaking changes or migrations
+
+### 3. Read GitHub Issue
+
+Fetch issue **#{issue-number}** details:
+- Get title for PR title
+- Extract acceptance criteria
+- Get any context from comments
+
+```bash
+gh issue view {issue-number} | cat
+```
+
+### 4. Run Final Validations
+
+```bash
+npm run lint --if-present
+npm run type-check --if-present
+if [ -f tsconfig.json ]; then npx tsc --noEmit; fi
+npm run test --if-present
+npm run build --if-present
+```
+
+Fix any issues before proceeding.
+
+### 5. Push Branch
+
+```bash
+git push -u origin $(git branch --show-current)
+```
+
+### 6. Create Pull Request
+
+#### PR Title
+```
+{Issue title}
+```
+
+#### PR Description
+
+Use this template:
+
+```markdown
+## Summary
+Brief description of what this PR accomplishes.
+
+## Related Issue
+Closes #{issue-number}
+
+## Changes Made
+- Change 1: Description
+- Change 2: Description
+- Change 3: Description
+
+## Type of Change
+- [ ] 🐛 Bug fix
+- [ ] ✨ New feature
+- [ ] 💥 Breaking change
+- [ ] 📝 Documentation
+- [ ] 🔧 Refactoring
+
+## Testing
+- [ ] Unit tests added/updated
+- [ ] Manual testing performed
+- Describe test cases here
+
+## Screenshots
+(If UI changes, add before/after screenshots)
+
+## Checklist
+- [ ] Code follows project style guidelines
+- [ ] Self-review completed
+- [ ] Documentation updated
+- [ ] Tests pass locally
+```
+
+#### Create via CLI
+
+```bash
+gh pr create \
+  --title "{Issue title}" \
+  --body "$(cat <<'EOF'
+## Summary
+...
+
+Closes #{issue-number}
+EOF
+)" \
+  --base "$BASE_BRANCH" | cat
+```
+
+#### PR Settings
+- **Source**: Current branch
+- **Target**: `<base-branch>` resolved from `.agents-toolkit.json` (fallback: `main`)
+- **Reviewers**: Based on changed files
+
+### 7. Comment on GitHub Issue
+
+Add a comment linking to the PR:
+
+```bash
+gh issue comment {issue-number} --body "## Pull Request Created
+
+PR: <pr-url>
+Branch: \`$(git branch --show-current)\`
+
+Work in progress. Review requested." | cat
+```

package/templates/shared/prompts/create-plan.prompt.md

@@ -55,6 +55,14 @@ High-level description of the solution.
 ### API Changes
 If applicable, document any API changes.
 
+### Caching Impact (Next.js)
+If the feature touches data fetching, routes, or `next.config`, state the caching plan:
+- Reads vs. mutations (mutations never cached; reads cache regardless of GET/POST)
+- `revalidate` tier + cache `tags` for any new fetches
+- Whether new routes export `revalidate`, and any on-demand invalidation (Next.js + CDN) needed
+
+See `.github/instructions/caching.instructions.md`.
+
 ## Risk Assessment
 
 | Risk | Probability | Impact | Mitigation |

package/templates/shared/prompts/finalize-github-pr.prompt.md

@@ -0,0 +1,129 @@
+---
+agent: agent
+description: Finalize a pull request after approval and prepare for merge
+---
+
+# Finalize GitHub Pull Request
+
+Finalize PR for GitHub issue **#{issue-number}** after approval and prepare for merge.
+
+## Prerequisites
+- PR has been approved
+- GitHub MCP connection or `gh` CLI required
+- Reference: `.github/prompts/_partials/git-operations.md`
+- Reference: `.github/prompts/_partials/validations.md`
+- Reference: `.github/prompts/_partials/github-integration.md`
+
+## Steps
+
+### 1. Verify PR Status
+
+```bash
+gh pr view --json state,reviewDecision,statusCheckRollup | cat
+```
+
+Check:
+- All required approvals in place
+- CI/CD pipeline passed
+- No unresolved review comments
+
+### 2. Address Review Comments
+
+If there are unresolved comments:
+
+```bash
+gh pr view --json reviews,comments | cat
+```
+
+- List each unresolved comment
+- Address feedback
+- Push additional commits if needed
+- Request re-review if changes are significant:
+
+```bash
+gh pr review --request-changes --body "..." | cat
+# or after fixing:
+gh pr review --approve | cat
+```
+
+### 3. Sync with Base Branch
+
+```bash
+BASE_BRANCH=$(node -e "try{const c=require('./.agents-toolkit.json');console.log(c.pr?.targetBranch||c.git?.defaultBranch||'main')}catch{console.log('main')}")
+git fetch origin
+git rebase "origin/${BASE_BRANCH}"
+```
+
+If conflicts:
+1. Resolve each conflict
+2. Stage resolved files: `git add <file>`
+3. Continue rebase: `git rebase --continue`
+
+Push updated branch:
+```bash
+git push --force-with-lease
+```
+
+### 4. Final Validations
+
+Run complete validation suite:
+```bash
+npm run lint --if-present
+npm run type-check --if-present
+if [ -f tsconfig.json ]; then npx tsc --noEmit; fi
+npm run test --if-present
+npm run build --if-present
+```
+
+Verify:
+- No regressions after rebase
+- All tests still pass
+- No new warnings
+
+### 5. Merge Pull Request
+
+**Recommended merge strategy**: Squash merge
+
+```bash
+gh pr merge --squash --delete-branch | cat
+```
+
+**Final commit message format**:
+```
+{Issue title} (#{pr-number})
+
+- Key change 1
+- Key change 2
+- Key change 3
+```
+
+### 6. Post-Merge Tasks
+
+After merge is complete:
+
+```bash
+# Return to base branch and sync
+git checkout "$BASE_BRANCH"
+git pull origin "$BASE_BRANCH"
+
+# Delete local branch (force if squash-merged)
+git branch -D <branch-name>
+
+# Clean up stale references
+git remote prune origin
+```
+
+### 7. Close GitHub Issue
+
+The issue closes automatically if the PR description contains `Closes #{issue-number}`.
+If not, close manually:
+
+```bash
+gh issue close {issue-number} --comment "Completed in PR #<pr-number>." | cat
+```
+
+### 8. Clean Up
+
+- [ ] Delete temporary planning docs from `docs/` (if applicable)
+- [ ] Ensure final documentation is complete
+- [ ] Verify commit history is clean

package/templates/shared/prompts/prepare-github-release.prompt.md

@@ -0,0 +1,134 @@
+---
+description: Prepare a GitHub release (version bump, changelog, tag/Release) — auto-detects WordPress vs Node projects and the correct tag-vs-Release flow
+agent: agent
+tools:
+  - run_in_terminal
+  - read_file
+  - replace_string_in_file
+  - create_file
+---
+
+# Prepare GitHub Release
+
+Prepare a new version release and drive it through the **correct GitHub flow** for the current
+project. This prompt is **project-agnostic**: it detects the ecosystem (WordPress plugin vs Node/npm
+package) and analyzes the repo's GitHub Actions workflows to decide whether a **bare tag** or a full
+**GitHub Release** is required.
+
+## Prerequisites
+- Reference: `.github/prompts/_partials/git-operations.md`
+- Reference: `.github/prompts/_partials/release-wordpress.md` (WordPress projects)
+- Reference: `.github/prompts/_partials/release-node.md` (Node/npm projects)
+- `gh` CLI authenticated. Releases are a GitHub concept — if the `origin` remote is **not** GitHub
+  (e.g. Bitbucket), stop and tell the user this flow does not apply.
+
+## Inputs
+
+Ask the user:
+1. **Version type** — `patch`, `minor`, or `major`? (default: patch). Suggest one from the
+   `[Unreleased]` changelog content: new features → `minor`, fixes only → `patch`, breaking → `major`.
+2. **Changelog entry** — reuse the existing `[Unreleased]` section if present, otherwise offer to
+   generate one from `git log` since the last tag.
+
+## Steps
+
+### 1. Detect host and project type
+
+```bash
+git remote get-url origin            # must be github.com — else stop
+git fetch --tags --quiet
+git tag --sort=-v:refname | head -1  # latest tag (current released version)
+```
+
+Detect the **project type** and follow the matching partial:
+
+| Signal | Project type | Use partial |
+|--------|--------------|-------------|
+| `*.php` with a `* Version:` plugin header | WordPress plugin | `release-wordpress.md` |
+| `package.json` (no WP header) | Node / npm | `release-node.md` |
+| neither | Generic | inline fallback: bump a `VERSION` file / changelog only |
+
+### 2. Determine the new version
+
+- Read the **current** version from the source of truth named in the matching partial (not just the
+  git tag — they can drift).
+- Apply the bump type to compute `X.Y.Z`.
+- **NEVER reuse an existing tag** — tags are immutable. If `vX.Y.Z` already exists, bump again.
+
+### 3. Run quality checks (per partial)
+
+Run the ecosystem's checks from the matching partial (WordPress: phpcs/phpstan; Node: `npm test` +
+lint/type-check/build). **Do not proceed if any check fails.**
+
+### 4. Bump the version (per partial)
+
+Update every version file listed in the matching partial (WordPress: plugin header / `readme.txt` /
+`composer.json`; Node: `package.json` + `package-lock.json`).
+
+### 5. Update CHANGELOG.md
+
+Promote the `[Unreleased]` section to the new version, keeping a Keep-a-Changelog structure:
+
+```markdown
+## [X.Y.Z] - YYYY-MM-DD
+
+### Added/Changed/Fixed
+- ...
+```
+
+If there is no `[Unreleased]` section, add a new `## [X.Y.Z]` block at the top with the changes.
+
+### 6. Create release branch, commit, and PR
+
+```bash
+BASE_BRANCH=$(node -e "try{const c=require('./.agents-toolkit.json');console.log(c.pr?.targetBranch||c.git?.defaultBranch||'main')}catch{console.log('main')}")
+git checkout -b release/vX.Y.Z
+git add -A
+git commit -m "chore: bump version to X.Y.Z"
+git push -u origin release/vX.Y.Z
+gh pr create --base "$BASE_BRANCH" --title "Release vX.Y.Z" --body "## Changes
+
+- changelog entry" | cat
+```
+
+### 7. Analyze workflows → decide tag-only vs GitHub Release
+
+**This is the critical step.** Read the repo's workflows and tell the user exactly what to do after
+the release PR merges:
+
+```bash
+ls .github/workflows/ 2>/dev/null
+# inspect the `on:` triggers and publish/build steps of each workflow
+```
+
+Decide from the triggers:
+
+| Workflow trigger | Post-merge action | Why |
+|------------------|-------------------|-----|
+| `on: release: [created\|published]` | **Create a GitHub Release** (`gh release create vX.Y.Z`) | A bare tag does **not** fire `release` workflows — publishing/build only runs on the Release event |
+| `on: push: tags: ['v*']` | **Push the tag** (`git push origin vX.Y.Z`) — Release optional | The tag push alone triggers the workflow |
+| neither / no workflow | **Push the tag** for history; optionally `gh release create` for visibility | No automation depends on it |
+
+Also scan the workflow **steps** and report what the release produces (e.g. `npm publish`, plugin
+ZIP artifact, Docker image) so the user knows what will happen.
+
+### 8. Post-merge instructions (tailored to step 7)
+
+Give the exact commands for the detected flow, e.g.:
+
+```bash
+git checkout "$BASE_BRANCH" && git pull
+git tag vX.Y.Z
+git push origin vX.Y.Z
+# If a `release:`-triggered workflow exists, ALSO create the Release so it fires:
+gh release create vX.Y.Z --generate-notes
+```
+
+## Important
+
+- **NEVER reuse an existing tag** — tags are immutable. If a tag exists, bump to the next version.
+- The `release-management` skill has full documentation for WordPress plugins — use it for troubleshooting.
+- Some projects use `master` instead of `main` — always verify the default branch with
+  `gh repo view --json defaultBranchRef | cat`.
+- A bare tag and a GitHub Release are **not** interchangeable: many publish/build workflows only run
+  on the `release` event. Always complete step 7 before telling the user the release is done.

package/templates/shared/prompts/review-code.prompt.md

@@ -56,6 +56,18 @@ For each changed file:
 - [ ] Efficient data structures
 - [ ] No memory leaks potential
 
+### 5. Caching & Data Fetching (Next.js)
+
+> See `.github/instructions/caching.instructions.md`. Caching is decided by **read-vs-mutation**, not the HTTP method.
+
+- [ ] Reads cache regardless of method — a `POST` read (e.g. `geo-search`) sets `next: { revalidate, tags }` (NOT `revalidate: 0`)
+- [ ] No `next: method === "GET" ? {...} : { revalidate: 0 }` gating (leaves POST reads uncached → route turns dynamic, `private, no-store`)
+- [ ] Mutations (`submit`/lead/`PUT`/`DELETE`) use `cache: "no-store"` and are never cached
+- [ ] `tags` always paired with a `revalidate` duration (no bare `next: { tags }`)
+- [ ] Cacheable routes export `revalidate`; not added to form/personalized routes
+- [ ] `React.cache()` not used as a substitute for cross-request caching
+- [ ] On-demand revalidation invalidates both Next.js (`revalidateTag`/`revalidatePath`) and the CDN
+
 ## Output
 
 ### Review Summary

package/templates/shared/prompts/work-github-issue.prompt.md

@@ -93,4 +93,4 @@ Report:
 
 - Begin implementation following the plan
 - Use `prepare-pr` when ready for review
-- Use `create-pr` to submit pull request
+- Use `create-github-pr` to submit pull request

package/templates/shared/skills/README.md

@@ -8,18 +8,39 @@ Skills are markdown files with YAML frontmatter that provide domain-specific gui
 
 ## Structure
 
-Each skill lives in its own folder with a `SKILL.md` file:
+Each skill lives in its own folder with a `SKILL.md` file. Following the
+[`npx skills`](https://github.com/vercel-labs/skills) standard, the real files
+are installed **once** into a canonical `.agents/skills/` store, and each agent's
+skills directory contains symlinks to it (single source of truth):
 
 ```
-.github/skills/
+.agents/skills/                       # canonical store (real files)
+├── ai-seo-optimization/
+│   └── SKILL.md
 ├── component-architecture/
 │   └── SKILL.md
+├── create-component/
+│   └── SKILL.md
 ├── domain-driven-design/
 │   └── SKILL.md
+├── plugin-creation/
+│   └── SKILL.md
+├── quality-checks/
+│   └── SKILL.md
+├── release-management/
+│   └── SKILL.md
+├── testing/
+│   └── SKILL.md
 └── testing-patterns/
     └── SKILL.md
+
+.github/skills/   → symlinks to ../../.agents/skills/*   (Copilot, Codex)
+.claude/skills/   → symlinks to ../../.agents/skills/*   (Claude Code, read natively)
 ```
 
+Use `--copy` at install time to materialize real copies instead of symlinks
+(symlinks also fall back to copies automatically on systems that don't support them).
+
 ## Frontmatter Format
 
 ```yaml
@@ -47,7 +68,8 @@ Skills are automatically picked up by agents when relevant to your question. You
 
 ## Creating Custom Skills
 
-1. Create a folder: `.github/skills/your-skill-name/`
+1. Create a folder: `.agents/skills/your-skill-name/` (canonical store)
 2. Create `SKILL.md` with frontmatter
+3. Run `npx @silverassist/agents-toolkit install --skills-only` to symlink it into `.github/skills/` and `.claude/skills/`
 3. Document patterns, examples, and conventions
 4. Include ✅ CORRECT and ❌ INCORRECT examples

package/templates/shared/skills/nextjs-caching/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: nextjs-caching
+description: Caching strategy for Next.js (App Router) frontends consuming the CCDS API and headless WordPress. Use when asked about caching, ISR, "revalidate", "stale data", "page not cached", "private / no-store header", POST requests not caching, CloudFront/CDN invalidation, `next: { revalidate, tags }`, or when a page unexpectedly renders dynamically.
+---
+
+# Next.js Caching Skill
+
+Canonical caching strategy for Silver Side Next.js (App Router) frontends. Use it when touching data
+fetching, route segment configs, the asset/page proxy, image config, or the on-demand revalidate
+route — and when diagnosing "why isn't this page cached / why is it serving stale".
+
+> Companion: `caching.instructions.md` (the short, auto-applied rules). This skill is the deep
+> reference and decision guide. If a project keeps a `docs/CACHING.md`, that is its project-specific
+> extension (endpoints, CloudFront IDs, per-route tiers) and is never overwritten by the toolkit.
+
+---
+
+## Core principle
+
+**Cache by intent (read vs. mutation), never by the HTTP method.** Some reads must use `POST` because
+they take a body (e.g. CCDS `geo-search`). They still have to cache like a `GET`. Mutations must never
+cache. Getting this wrong silently turns a static page into a per-request dynamic render.
+
+---
+
+## The caching layers (independent)
+
+Fixing one does **not** fix the others.
+
+| # | Layer | Where | Purpose |
+|---|-------|-------|---------|
+| 1 | ISR / page cache | `export const revalidate` per route | Time-based regeneration of rendered pages |
+| 2 | Data-fetch cache | `next: { revalidate, tags }` on each `fetch` | Cross-request caching of CCDS/WP responses |
+| 3 | Request dedup | `React.cache()` around client fns | Collapse duplicate calls within one render |
+| 4 | Asset proxy | `src/app/assets/[...path]/route.ts` | Long-lived `Cache-Control` on WP images/CSS/fonts |
+| 5 | Edge / CDN | `src/proxy.ts` + CloudFront | `s-maxage` at the edge + on-demand invalidation |
+
+**Layer 2 is the most commonly broken.** A page can be ISR-enabled (layer 1) yet still hit origin on
+every request if its data fetches (layer 2) are not cached — and an uncached fetch also forces the
+whole route into **dynamic rendering**, which emits `cache-control: private, no-cache, no-store`.
+
+---
+
+## How Next.js 16 actually decides (the rule behind the rule)
+
+From `next/dist/server/lib/patch-fetch.js`:
+
+- `fetch` is **not cached by default**. A non-`GET` method is "uncacheable" **only when no explicit
+  cache config is provided**. Concretely, a POST is auto-no-cached only when it has no `next`/`cache`
+  options *and* the segment `revalidate` is `0`.
+- Therefore **a `POST` IS cached cross-request when you pass an explicit `next: { revalidate }`** (and
+  the segment isn't `revalidate: 0`). This is why the WordPress GraphQL POST caches fine.
+- The **request body is part of the cache key** (`incremental-cache` → `generateCacheKey` hashes
+  `init.body`), so different filter bodies cache independently and never collide.
+
+**Implication:** you do **not** need `unstable_cache` or a proxy header override to cache POST reads.
+Just send `next: { revalidate, tags }`.
+
+---
+
+## Canonical API client (read vs. mutation)
+
+```ts
+interface FetchOptions {
+  endpoint: string;
+  method?: "GET" | "POST" | "PUT" | "DELETE";
+  body?: object | null;
+  revalidateTag?: string;
+  revalidate?: number;
+  /** Writes are never cached. Reads (default) cache regardless of method. */
+  mutation?: boolean;
+}
+
+export async function fetchData<T>({
+  endpoint,
+  method = "GET",
+  body = null,
+  revalidateTag,
+  revalidate = 86400, // 24h time-based fallback; pair with tags for surgical invalidation
+  mutation = false,
+}: FetchOptions): Promise<T | null> {
+  const isMutation = mutation || method === "PUT" || method === "DELETE";
+
+  const requestOptions: RequestInit = {
+    method,
+    // Reads (GET or POST) cache cross-request via `next`; mutations opt out.
+    ...(isMutation
+      ? { cache: "no-store" as RequestCache }
+      : { next: { revalidate, tags: revalidateTag ? [revalidateTag] : [] } }),
+  };
+
+  if ((method === "POST" || method === "PUT") && body) {
+    requestOptions.body = JSON.stringify(body);
+  }
+  // ...fetch + error handling...
+}
+```
+
+Mark every write explicitly:
+
+```ts
+await fetchData({ endpoint: "community/submit-review", method: "POST", body, mutation: true });
+```
+
+WordPress GraphQL client (POST read — must carry `next`):
+
+```ts
+await fetch(WP_API_URL, {
+  method: "POST",
+  body: JSON.stringify({ query, variables }),
+  next: { revalidate, ...(tags && { tags }) }, // a POST IS cacheable WITH next options
+});
+```
+
+---
+
+## ISR revalidate tiers
+
+| Route type | `export const revalidate` |
+|------------|---------------------------|
+| Listing / index | `2592000` (30d) — webhook handles freshness |
+| Detail / city / community (`[slug]`) | `86400` (24h) |
+| State / advisor landing | `604800` (7d) |
+| WP catch-all (`[[...uri]]`) | `604800` (7d) |
+
+- Every cacheable route exports `revalidate`. Do **not** add it to form/personalized routes.
+- Prefer `export const revalidate` over `dynamic = "force-static"`: a failed ISR revalidation then
+  preserves the last good cache instead of overwriting it with a broken page. Pair with a client that
+  **throws on 5xx at runtime** (so ISR keeps the previous version) but returns an error during the
+  build phase (so `generateStaticParams` can skip a bad entry without failing the build).
+
+---
+
+## On-demand revalidation (dual invalidation)
+
+`/api/revalidate` must invalidate **both** layers in one request, or the CDN serves stale until its
+own TTL expires:
+
+```ts
+revalidatePath(path, "page");        // or "layout"
+revalidateTag(tag);                  // granular per-state / per-city tags
+if (invalidateCDN) await invalidateCloudFrontPaths([path]);
+```
+
+---
+
+## Anti-patterns
+
+- ❌ `next: method === "GET" ? {...} : { revalidate: 0 }` — leaves POST reads uncached → the route
+  renders dynamically (`private, no-store`). This is the exact regression that broke city pages.
+- ❌ Bare `fetch(url, { method: "POST", body })` for a read — refetched from origin every render.
+- ❌ `next: { tags }` with no `revalidate` — holds stale data or doesn't cache at runtime.
+- ❌ Caching a mutation (`submit`, lead, `PUT`/`DELETE`/`PATCH`).
+- ❌ Treating `React.cache()` as cross-request caching (it's request-scoped dedup only).
+- ❌ `dynamic = "force-static"` on a page whose revalidation can fail (caches a broken page).
+- ❌ Mixing `cacheComponents: true` (`"use cache"`) with route-segment `export const revalidate` —
+  that is a separate, deliberate migration; do not introduce it ad hoc.
+
+---
+
+## Diagnosing "page is not cached"
+
+1. **Check the response header.** `cache-control: private, no-cache, no-store` ⇒ the route is rendering
+   dynamically. Something opted it into dynamic rendering.
+2. **Find the dynamic trigger.** Usually an uncached fetch (a POST read without `next`, or
+   `revalidate: 0`), or a request-time API (`cookies()`, `headers()`, `searchParams`).
+3. **Fix layer 2 first.** Give read fetches `next: { revalidate, tags }`; mark mutations `no-store`.
+4. **Confirm the route exports `revalidate`.**
+5. **Reconcile CDN vs. ISR TTLs.** If ISR is 24h but CDN `s-maxage` is shorter, an ISR revalidation
+   should trigger a CloudFront invalidation for that path.
+
+---
+
+## Verification
+
+```bash
+# A POST-read page (e.g. a city) must be publicly cacheable:
+curl -sI https://<host>/<care-type>/<state>/<city> | grep -i cache-control
+# expect: cache-control: public, ...   (NOT private/no-store)
+```
+
+In the build output, `●` (or "Static"/"ISR") means prerendered; `ƒ` ("Dynamic") means it renders per
+request — a POST-read page should be the former. `next.config` `logging.fetches.fullUrl: true` shows
+per-fetch cache decisions in dev.