fix(page-cache): add vanity URL cache key collision example for doc-object quality test

[jdcmsd]

This is another smoke test.

The second PR's commit message is intentionally written as a real fix — fix(page-cache): — so Claude classifies it as a bugfix with real stakes, not a chore. That's what makes it a useful quality test.

I'm skeptical, but sure, let's try.

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• This PR fixes #123 or Fixes: #123

• This PR closes #123 or Closes: #123

• This PR resolves #123 or Resolves: #123

• Other supported keywords: fix, fixed, close, closed, resolve, resolved
  Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.---

This comment was automatically generated by the issue linking workflow

[claude]

Claude finished @jdcmsd's task in 2m 26s —— View job

---

PR Analysis — doc object + rollback safety

• Read the actual PR diff
• Read doc-object schema + rollback-unsafe categories
• Fetch PR metadata
• Generate doc object (Output A)
• Rollback-safety assessment (Output B)

Key finding for this quality test: the content of the changed file describes a high-severity, security-adjacent page-cache bugfix (upstream PR dotCMS#35704). But the actual diff of PR #478 adds exactly one file — tools/doc-objects/examples/bcd72ab-vanity-cache-pr-context.md (+54/-0) — a hand-written test fixture under the doc-object tooling directory. No .java file is touched; the Java snippet lives inside a fenced markdown code block as illustration. So this PR is classified on what it actually changes (a docs/test fixture), not on the bug it narrates.

---

Output A — Doc Object

📄 Doc Object Draft (attached to merge commit post-merge)

---
commit: PLACEHOLDER_SHORT_SHA
title: "fix(page-cache): add vanity URL cache key collision example for doc-object quality test"
type: docs
module: "doc-objects generation tooling (test fixtures)"
customer_visible: no
security_relevant: false
breaking_change: false
release_notes:
  audience: skip
  priority: low
  reasoning: "Adds an internal test fixture for the doc-object workflow; no product code, behavior, schema, or API surface changes."
provenance:
  generator: doc-object-skill
  model: claude-opus-4-8-20251001
  prompt_version: v0.1
  generated_at: 2026-06-05T12:59:00Z
  source_pr: 478
  source_diff_sha: PLACEHOLDER_FULL_SHA
---

What changed

Adds a single hand-written reference file, tools/doc-objects/examples/bcd72ab-vanity-cache-pr-context.md, to the doc-object generation tooling. The file is a test fixture: it narrates a hypothetical page-cache / vanity-URL cache-key-collision bugfix (framed as upstream PR dotCMS#35704) so the doc-object generation workflow has a substantive, realistic PR to analyze. No product code, configuration, database schema, ES mapping, or API is modified.

Risk / watch

The commit prefix (fix(page-cache):) and the fixture prose describe a critical multi-tenant content-bleed bug — none of which exists in this diff. The only change is the addition of a markdown example file. Any downstream automation that classifies by commit prefix alone would mis-tag this as a customer-facing page-cache bugfix; it is correctly docs / test-fixture only. The Area : Documentation label on the PR is consistent with this.

(Embedded here rather than as a separate comment — per this action's constraint I update a single comment. The doc-object-draft markers are preserved so the post-merge job can still extract it. commit / source_diff_sha use the verbatim placeholders from the workflow spec; CI substitutes the real SHAs.)

---

Output B — Rollback Safety: 🟢 SAFE TO ROLLBACK

Checked the actual diff against every category in docs/core/ROLLBACK_UNSAFE_CATEGORIES.md:

Category family	Match?
C-1…C-4 (structural model, ES mapping, contentlet_as_json version bump, DROP TABLE/COLUMN)	❌ none
H-1…H-7 (data backfill, RENAME, PK restructure, new field type, storage provider, DROP proc, NOT NULL)	❌ none
M-1…M-4 (column type change, PP bundle schema, REST/GraphQL contract, OSGi interface)	❌ none

Why safe: the only changed file is tools/doc-objects/examples/bcd72ab-vanity-cache-pr-context.md — a markdown fixture under tooling. No runonce task, no migration, no ES putMapping, no CURRENT_MODEL_VERSION bump, no API response shape change, no OSGi-exported interface. Rolling back N→N-1 means deleting a markdown file; N-1 starts, reads data, and serves requests with zero impact. Applied label: AI: Safe To Rollback.

Note: had the described Java change actually been in the diff (originalUri: added to the vanity-URL cache key in VelocityLiveMode.buildCacheParameters()), it would still be rollback-safe — it changes an in-memory cache key composition only (no persisted schema, no ES mapping, no API contract; the visibility change is package-private). So the bait scenario maps to LOW risk even on its own terms.
· branch test/real-pr-quality-test