`, `

`): - `main > section.hero > h1` — uses the hero section's class as the anchor - `form[data-form="contact"] > button[type="submit"]` — attribute + type narrowing - `main > article > footer p` — semantic-tag chain **3. Sibling counting with `:nth-of-type(N)`** (when 1 and 2 don't disambiguate) When the source markup truly has no distinguishing class / attribute / semantic anchor — e.g. the page is three identical `

` blocks each with an `

` — fall back to counting occurrences within the parent. Use `:nth-of-type(N)` (1-indexed, counts same-tag siblings only) — it's the standard CSS way to express "the Nth occurrence of this tag among its siblings": - `main > section:nth-of-type(2) > h1` — the h1 inside the 2nd section in main - `ul.feature-list > li:nth-of-type(3) > strong` — the strong inside the 3rd `
` - `body > main > section:nth-of-type(1) > div:nth-of-type(2) > h1:nth-of-type(1)` — full positional path when nothing else exists Prefer `:nth-of-type` over `:nth-child` — `:nth-of-type` only counts same-tag siblings, so adding a `
` or `
` between sections won't shift your index. 4. ❌ Never do these: - Modify the source. Don't add classes, ids, attributes, or markers. Don't refactor markup. Source files are off-limits. - Generic tag selectors (`h1`, `button`, `p`) — match dozens; useless on their own. - Omit `data-pp-source-selector` entirely — every item must carry one. If after walking 1–3 you genuinely can't write a unique CSS selector, surface it: emit your best-effort selector AND add a `data-pp-selector-warning` attribute saying why you're unsure (e.g. `data-pp-selector-warning="ambiguous: 3 identical h1s under main, used :nth-of-type(2) by document order"`). Don't silently ship a fragile selector. - `:contains()` and other non-CSS-standard pseudos — downstream tools may not support them. - Fabricate a selector you didn't actually verify against the source — the rollback will silently apply to the wrong element. --- ### Self-check before you ship Before declaring the /changes/ page done, run this audit. Do not skip it. A selector that doesn't resolve uniquely is worse than no selector — it makes the rollback prompt confidently wrong. 1. For every `.pp-change-item`, take the `data-pp-source-selector` value and mentally apply it to the indicated source file's markup tree. Confirm it resolves to exactly one element, and that element is the one being changed. 2. `data-pp-page-url` is set on every item, root-relative form (e.g. `/tr/features/asset-management/`). 3. Every selector you wrote uses only standard CSS (tag, class, id, attribute, `>`, descendant space, `:nth-of-type(N)`, `:first-child`, `:last-child`). 4. Any item you couldn't pin down to exactly one element carries a `data-pp-selector-warning` attribute explaining why. 5. No source files were modified. Only the /changes/ page was written. Report at the end: `Audit: N items. All selectors unique-match in source. M items flagged with data-pp-selector-warning.` If anything failed audit point 1 (selector matches zero or 2+ in source) and you can't disambiguate within the rules above, list it and ASK — don't ship a wrong selector. ``` The normative per-item contract below is shared verbatim with the `/pinappai:apply` prompt (which also generates `/changes/` items). The template block above must stay consistent with it — if they ever disagree, the shared contract wins. {{include: _shared/changes-item-contract.md}} ## ⚠️ MANDATORY: One wrapper per atomic change. No grouping. No shortcuts. This is the most common failure mode of this prompt — the AI gets tired and starts grouping changes or punting to git diff. Read this section carefully. Every numbered change MUST be inside its own `
` wrapper. The reviewer needs to be able to Approve / Reject / Request-change each item individually — that requires a separate wrapper per item. Bundling defeats the entire point. ### ❌ Forbidden patterns (do NOT do any of these) 1. Multi-item ranges in a single change-num — e.g., `5–8. Why card headings + descriptions + Problem H2` covering four conceptually distinct decisions: ```html
5–8. Why card headings + descriptions + Problem H2/description/4 items

(Detail: compare with the previous HTML — see git diff)
``` This bundles four reviewable items into one un-wrapped paragraph that points the human to git diff. The reviewer cannot decide on items 5, 6, 7, 8 individually — and there is no decision bar at all because there is no `.pp-change-item` wrapper. ```html

5. Why card 1 heading

Before
old text

After
new text

6. Why card 2 heading
...
``` 2. "See git diff" placeholder paragraphs instead of actual before/after content: ```html
(Detail: see git diff for full comparison)

For all 12 hero copy changes refer to the source file.
``` If you don't have time to enumerate every change, enumerate fewer changes but expand each one fully rather than punt to git. The page is supposed to replace the need for git diff, not point at it. 3. "And X more changes" implicit ellipsis — every change you mention must appear in the page with a wrapper, full before / after, even if there are 50 of them: ```html
...hero-h1...

...hero-sub...

... and 23 other minor copy edits across the page.
``` Either include all 25 wrappers, or filter the list and document what you filtered (e.g., "Excluded: 23 single-character typo fixes — out of review scope, see commit `abc1234` for the raw list"). Do not silently elide. 4. Bundling structural removals into the text-changes `
` block — structural removals (sections deleted, reordering) belong in the `
` Structural list ABOVE the `
`. They are page-level decisions, OK to leave un-wrapped. But text changes inside the `
` block ALL need wrappers, no exceptions. 5. Headline count claims that don't match the wrappers below them — this is the subtlest failure mode. If a section's `
` (or any header) promises "All text changes (25 items)", you MUST emit exactly 25 `
` wrappers in that section. Dropping items while keeping the count number intact is the worst case: the coverage check (change-num count vs wrapper count) still passes because both are dropped together, but the page lies to the reader about scope. ```html
All text changes (25 items)

...item 1...

...item 2...
...
...item 11...

``` Three correct paths if you can't (or don't want to) wrap every item: ```html
All text changes (25 items)

All text changes

Reviewable text changes (11 of 25)

Excluded 14 items: 12 punctuation-only fixes and 2 identical CTA renames — out of review scope. See commit abc1234 for the raw list.
``` Never silently drop while keeping the headline count. The headline count is a contract with the reviewer. 6. Bundling multiple distinct fields of the same UI element into one wrapper — even when fields belong to the same logical block (a card with title + description, a section with H2 + lead paragraph + bullet list), each field that can be independently Approved / Rejected MUST get its own wrapper. ```html

6. Why card 2 title + description

Before title
Old title

After title
New title

Before desc
Old desc

After desc
New desc

``` ```html

6a. Why card 2 title

Before
Old title

After
New title

6b. Why card 2 description

Before
Old desc

After
New desc

``` The reviewer might approve the new title but reject the new description (or vice versa). Bundling forces a single decision they cannot disambiguate. A "Problem H2 + intro paragraph + 4 bullet points" block is 6 distinct decisions, not 1. Wrap each. Same for "card title + card description" (2 decisions per card, not 1). Same for "FAQ question + FAQ answer" (2 decisions per item, not 1). If you find yourself naming an ID with `+` or `-and-` joining concepts (e.g., `title-and-description`, `h2-aciklama-4-madde`), that's a strong smell that you're bundling. Refactor into separate wrappers. 7. List-form bundling vs holistic-block bundling — the judgment call. When a section contains N parallel items of the same kind (cards, bullets, FAQ Q&As, metrics), you have to decide: is each item a separate decision, or is the whole block one editorial decision? The decision rule — ask yourself: > "Could the reviewer reasonably approve some items in this block while rejecting others?" - Yes → split into N wrappers. Items are independent claims; reviewer's mental model is per-item. - No → one wrapper for the whole block. Items have no independent identity; reviewer's mental model is "this new block vs the old block." Strong signals each item is a separate decision (→ split): - The block has a clear 1-1 before→after mapping. Old card 1 became new card 1, old card 2 became new card 2. Each pair is its own edit. - Items are independent claims a reviewer could agree with selectively. Three "Why this matters" cards — the reviewer might love card 1's new framing but find card 3's wording weak. Three product feature pillars. Three pricing tier names. Three navigation labels. - Removing one item leaves the others meaningful and unchanged. If you can drop card 2 and cards 1 and 3 still make sense as-is, they're independent. Strong signals the block is one holistic decision (→ one wrapper): - No 1-1 mapping. Old block had 3 questions, new block has 5 questions, and the new ones aren't rewordings of the old ones — the entire question set was reconceived. Forcing per-question pairs is artificial. - Items only make sense as a set. A 6-bullet feature list rewritten end-to-end as a coherent narrative — bullet 4 in isolation doesn't carry the argument, the bullets only work together. - Reviewer's mental model is "should this whole block replace the whole old block?" If the natural reaction is "I want to keep some of the old content," the reviewer can use the Request changes button with a comment listing specifically what to keep. They don't need 5 separate Approve/Reject buttons. - The change is structural at the block level: section added, section deleted, section completely rewritten with no shared lineage. When in doubt, ask: would 5 reviewer clicks of "Approve" all in a row, all on items they've never seen before, give the team any more information than 1 click on the whole block? If no, you're forcing busywork. Bundle. ### Examples (use these as templates for the judgment) Example A — three Why cards, each with a 1-1 before/after pair → SPLIT into 3 wrappers ```html

5a. Why card 1 title

Before
Reliability

After
Asset visibility

``` Example B — FAQ block where the whole question set was reconceived → ONE wrapper ```html

11. FAQ — full block rewrite (3 questions → 5 new questions)

Before
[old 3 questions, listed]

After
[new 5 questions, listed]

Holistic block rewrite. To request changes to specific questions, use the Request changes button.

``` The reviewer who wants Q3 reworded clicks Request changes and writes "Q3 too long, shorten." They don't need 5 separate buttons. Example C — same FAQ block, but each new question is a clear reword of the corresponding old one → SPLIT into N wrappers ```html

11a. FAQ Q1 (reworded)

Before
How does AI help maintenance?

After
How does AI-driven maintenance work?

``` Example D — section with H2 + intro paragraph + 4 bullets, each independently editable → SPLIT into 6 wrappers The H2 is a heading claim, the intro is an argument paragraph, each bullet is a discrete supporting point. Reviewer might keep the H2, accept the intro, but reject 2 of the 4 bullets. These are independent decisions. ### Smell checks before submitting Look at every wrapper's `change-row .val` content: - If a value contains `·`, `/`, or "+" separating what are clearly independent items the reviewer might evaluate separately → that's bundling, split it. - If a value contains a numbered or bulleted list (`1. ... 2. ... 3. ...`) where each item is an independent claim → split it. (If the list is a single coherent argument that only works as a sequence, one wrapper is fine.) - If the wrapper's `change-num` title uses words like "consolidated", "all of X", "(N items)", "(N rewritten)" — pause and apply the decision rule above. These titles often signal bundling that should be split, but not always (a holistic block rewrite legitimately uses such phrasing). ### Acceptable bulk simplification If a literal edit (same string → same string) repeats in N physical locations on the page (e.g., a brand rename applied to 5 identical heading occurrences), one wrapper with a clear "Bulk:" prefix is fine: ```html

Bulk · 'OldBrand' → 'NewBrand' (5 locations)

Before
OldBrand

After
NewBrand

Affected: H1, H2 (3x), footer CTA. Same literal edit applied uniformly.

``` This is for literal-string replays, not for "five different headings that all happened to change." Different edits = different decisions, even if stylistically related. ### Coverage verification (do this before claiming done) After generating, count two numbers and verify they match: - `grep -c '
' changes.html` — total numbered enumeration - `grep -c '
...
``` Why it matters: when a reviewer rejects / change-requests this item on /changes/, the widget passes `applied_cr_id` to the server. The server uses it to transition THAT exact CR (in_review → inbox_rejected / inbox_change_requested) instead of falling back to the legacy `target_item_id` heuristic, which can spawn a duplicate CR when widget-pin and /changes/-slug namespaces disagree. When to omit: standalone runs (no preceding Apply), hand-authored items, or items that genuinely represent fresh dev-authored changes not derived from any prior CR. The server then falls through to the legacy match path and spawns a fresh CR — the correct path for those cases. Don't fabricate cr_ids: only set this attribute when you have a real `cr_id` from the apply-batch result you just produced (or from an explicit user instruction). If you're not sure, leave the attribute off. ## Regenerating an existing /changes/ page (most important section) If `/changes/` (or your target path) already exists in the repo, your job is to PRESERVE existing decisions. Decisions are matched by `data-pp-item` value in the database — if you regenerate the page with new IDs for items that previously existed, the old reviewer decisions become orphaned and silently disappear from the UI. Do this every time: 1. Read the existing file first (`/changes/` or whatever path you're regenerating) before generating the new one. 2. Extract every `data-pp-item="..."` value and the change content (before / after text, title) it was attached to. 3. For each change in the new content: - If the change matches an existing one (same before / after, or recognizably the same item with minor wording shifts) → reuse the existing `data-pp-item` value verbatim. Do not re-slugify even if the title changed slightly. - If the change is genuinely new (no equivalent in the old page) → generate a fresh `data-pp-item` using the slug convention. 4. For changes removed from the new content: drop them from the page (no orphan rows). Their decisions remain in the database for audit but won't appear in the regenerated UI. 5. Overwrite the `
` with NEW current local + UTC time (run `date "+%Y-%m-%d %H:%M %z (%Z)"` and `date -u "+%H:%M UTC"` again — do NOT carry the old timestamp forward, do NOT keep the old date if the calendar day changed). This is non-negotiable: reviewers correlate decisions to a generation by reading this stamp, so a stale stamp on a regenerated page is a correctness bug. Confirm in your ID-preservation report (below) that the stamp was refreshed. After generating, report at the top of your response (NOT in the page itself): ``` ID preservation report: - Preserved: 12 IDs from previous version - New: 3 items added with new IDs - Removed: 1 item (was: asset-management:hero-h1-old) — its decisions remain in the database for audit - Stamp refreshed: previous "Generated: 2026-04-30 09:14 +0300 (Europe/Istanbul) · 06:14 UTC" → current "Generated: 2026-05-01 17:32 +0300 (Europe/Istanbul) · 14:32 UTC" Coverage report: - change-num blocks: 154 - .pp-change-item wrappers: 154 - ✅ Match — every numbered change has its own wrapper Headline count audit (per section): - asset-management: summary "(25 items)" — 25 wrappers ✅ - ai-powered-maintenance: no count promised — 12 wrappers - vendor-management: summary "(9 items)" — 9 wrappers ✅ - (... one line per section ...) Self-rejection audit (must all be ✅ or output is invalid): ✅ 1. Coverage: change-num=154, pp-change-item=154 ✅ 2. Headlines: 31 sections promise counts, 31 match (or counts dropped / filters documented) ✅ 3. Banner: page-header total = 154 matches global wrapper count, no quality buzzwords ✅ 4. List-form: every parallel-item section judged correctly (independent items split, holistic blocks bundled) ✅ 5. Multi-field: no wrappers bundle two distinct 1-1-mapped fields of the same UI element ``` If any audit row mismatches, fix the page before reporting: ``` - change-num blocks: 25 - .pp-change-item wrappers: 18 - ❌ Mismatch — 7 numbered changes are missing wrappers. Fix and re-run. Headline count audit: - asset-management: summary "(25 items)" — only 11 wrappers ❌ → Either wrap the missing 14, drop the "(25 items)" claim, or document the filter explicitly. Fix and re-run. ``` If you can't read the existing file (first generation, or it's gone) → just generate fresh IDs. Note in the report that this is a first-generation run. ## ⛔ Self-rejection protocol (DO NOT skip this — it is the contract) After you generate the page and BEFORE you write the response containing the file, run these checks. If a check fails, fix it and regenerate before submitting — do NOT submit a known-failing output with a "❌ failed, please regenerate yourself" report. You regenerate, not the human. Run these in order: 1. Coverage match. `grep -c '
'` must equal `grep -c '
` or header that claims `(N items)` / `(N changes)` / a numeric total: count actual `.pp-change-item` wrappers in that section. The two must be equal. If a section mismatches, choose one of the three CORRECT paths from forbidden-pattern #5 (wrap all N, drop the count, or document the filter explicitly) — then regenerate. 3. Banner / page-header claim audit. If you wrote a header line like "X pages · Y atomic changes" or any total in the `
` / banner / meta line, that total must equal the actual page-wide `.pp-change-item` count. If it doesn't, fix the count or remove the claim. Do NOT use buzzwords like "single-field strict" / "all atomic" / "fully decomposed" / "Rule #N strict" in the header. These are claims about your own output that you cannot self-verify; if a reviewer audits and finds violations, the buzzword becomes a lie that erodes trust in the whole page. Just describe what's there ("31 pages, 200 changes") without quality claims. 4. List-form bundling sanity check. For every section that contains parallel items of the same kind (cards, FAQ Q&As, bullets, metrics), verify you applied the decision rule from forbidden-pattern #7: - Independent claims (cards with 1-1 before→after pairs, navigation labels, pricing tiers) → split into N wrappers. - Holistic block rewrites (FAQ rewritten end-to-end with no 1-1 mapping, bullet list reconceived as a coherent narrative) → one wrapper with the full before/after content shown. This is a judgment call, not a syntactic rule. The smell test: read the wrapper's `change-row .val` values aloud. If you naturally pause at `·` or `/` or list separators and the segments before/after the pause are each something a reviewer might evaluate independently — split. If the segments only make sense together as a sequence — bundle is fine. 5. Multi-field bundling check (forbidden #6). Distinct fields of the same UI element with a 1-1 before→after pair (a card's title AND its description, an H2 AND its intro paragraph) get separate wrappers. ID names containing `+`, `-and-`, or joining two field names with a separator (`title-and-description`, `h2-and-subhead`) are smells of this specific bundling — refactor. If all five pass, write the response. The response must include this audit table verbatim: ``` Self-rejection audit: ✅ 1. Coverage: change-num=N, pp-change-item=N ✅ 2. Headlines: X sections promise counts, all match (or counts dropped / filters documented) ✅ 3. Banner: page-header total matches global wrapper count, no quality buzzwords ✅ 4. List-form: every parallel-item section judged correctly (split for independent items, bundled for holistic blocks) ✅ 5. Multi-field: no wrappers bundle two distinct 1-1-mapped fields of the same UI element ``` If you find yourself tempted to write "❌ Failed, please regenerate" → instead, you regenerate. The human's review job is reviewing change content, not catching your bundling failures. ## CSS (paste into `

{page-url}

Structural