@sellable/mcp 0.1.255 → 0.1.257

package/skills/create-post/references/hook-research-playbook.md

@@ -28,10 +28,11 @@ Worker owns:
 - tracked-person post fetches
 - full-text matching by URL/activity ID
 - duplicate removal
+- follower-band and reach-normalized signal scoring
 - lead-magnet, giveaway, engagement-bait, and off-voice filtering
 - market belief mapping across kept and rejected examples
 - premise input extraction: real scenes, observed tensions, reader value, proof gaps
-- hook opening measurement
+- rendered hook opening measurement
 - exact phrase-pattern extraction
 - body-structure extraction
 - rejected-example notes
@@ -58,7 +59,8 @@ Research packet:
 - exact phrase patterns: max 20
 - body patterns: max 8
 - source URLs and author profile URLs
-- preview measurements
+- reach-normalized signal notes
+- rendered preview records
 - confidence gaps
 - save recommendations
 ```
@@ -74,6 +76,13 @@ Use `mcp__sellable__search_engagement_posts` with practical constraints:
 
 - explicit `maxAgeDays: 120` by default so research covers the past 30-120 days, not only this week's posts
 - tighten to 30-60 days for trend-sensitive topics; widen only when the topic has low volume
+- when the user gives a follower range, pass it as `targetFollowerMin` and
+  `targetFollowerMax` so the tool can expose reach-normalized signals and
+  prioritize comparable creators
+- if a source hook looks promising but follower count is missing, use
+  `mcp__sellable__fetch_linkedin_profile` on a bounded shortlist before calling
+  the source a keeper; if profile fetch is unavailable or too slow, mark
+  `follower_count_unavailable`
 - high enough engagement to matter
 - narrow enough to match the idea
 - enough result depth to see whether a creator has repeated winners, not just one viral outlier
@@ -82,14 +91,19 @@ Record every keyword, filter, search window, page, and result count.
 
 ## Weighted Signals
 
-Rank source posts with a weighted signal view. Do not sort by total engagement alone.
+Rank source posts with a weighted signal view. Do not sort by total engagement
+alone. Use the numeric score to decide which sources deserve study; do not let
+the number choose the final hook by itself.
 
 Use this scoring shape:
 
 ```text
 hook_score =
   topic_fit
+  + rendered_mobile_preview_strength
   + hook_clarity
+  + content_pattern_replicability
+  + reach_adjusted_evidence
   + creator_repeat_success
   + repost_share_strength
   + comment_quality
@@ -107,6 +121,135 @@ Guidance:
 - If share or repost data is unavailable, record `repost_data_unavailable` instead of inventing it.
 - Prefer creators with repeated high-performing posts in the same lane over one-off viral posts.
 
+## Reach-Normalized Hook Scoring
+
+Raw engagement is not the clearest signal when source creators have wildly
+different audience sizes. A post from a 100k+ follower creator can win on
+distribution even when the hook is ordinary. A post from a creator near the
+user's follower range that overperforms is a clearer signal that LinkedIn and
+readers rewarded the hook/premise.
+
+This calculation is a source-quality filter, not the final creative decision.
+After reach is controlled, the LLM still chooses the hooks to steal based on the
+visible hook, rendered first-screen promise, content pattern, premise fit, and
+whether the idea can carry without the source creator's distribution.
+
+When the user gives a target range, default to that range. For example, if the
+user says "8k to 20k followers," call `mcp__sellable__search_engagement_posts`
+with:
+
+```text
+targetFollowerMin: 8000
+targetFollowerMax: 20000
+```
+
+If the user gives no range, use the user's known follower count from memory or
+ask only when the decision depends on it. If no follower count is available, use
+raw engagement as a fallback and mark `target_follower_band_unknown`.
+
+For every shortlisted source post, record:
+
+- `authorFollowerCount`
+- `targetFollowerBand`
+- `followerBandFit`: `in_target_band`, `below_target_band`,
+  `above_target_band`, or `unknown`
+- `engagementPer1kFollowers`
+- `weightedEngagementPer1kFollowers`
+- `reachAdjustedScore`
+- `creatorBaselineMedianEngagement` when repeated posts from that creator are
+  available
+- `baselineLift`: this post's engagement divided by the creator's recent median
+  engagement in the same lane, or `creator_baseline_unavailable`
+- `confidence`: `high`, `medium`, or `low`
+- `normalizationNotes`
+
+Use this Harvest-compatible calculation when follower counts are available:
+
+```text
+weightedEngagement =
+  likes
+  + (comments * 4)
+  + (shares * 12)
+
+engagementPer1kFollowers =
+  totalEngagement / authorFollowerCount * 1000
+
+weightedEngagementPer1kFollowers =
+  weightedEngagement / authorFollowerCount * 1000
+
+reachPenaltyMultiplier =
+  1.00 when in target follower band
+  0.75 when below target band
+  0.65 when above target band but <= 2x target max
+  0.35 when above target band but <= 5x target max
+  0.15 when above target band and > 5x target max
+  0.40 when follower count is unknown
+
+reachAdjustedScore =
+  weightedEngagementPer1kFollowers * reachPenaltyMultiplier
+```
+
+When repeated posts from the same creator are available, calculate:
+
+```text
+creatorBaselineMedianEngagement =
+  median weightedEngagement across recent same-lane posts
+
+baselineLift =
+  post weightedEngagement / creatorBaselineMedianEngagement
+```
+
+Use this scoring shape when deciding which hooks to study:
+
+```text
+hook_score =
+  topic_fit
+  + rendered_mobile_preview_strength
+  + hook_clarity
+  + same_follower_band_bonus
+  + weighted_engagement_per_1k_followers
+  + creator_baseline_lift
+  + repost_share_strength
+  + substantive_comment_quality
+  + creator_repeat_success
+  - celebrity_reach_penalty
+  - tiny_sample_penalty
+  - lead_magnet_penalty
+  - engagement_bait_penalty
+  - off_voice_penalty
+```
+
+Rules:
+
+- Prefer in-band creators when the hook is strong and the engagement is real.
+- Use near-band creators as secondary evidence.
+- Penalize creators far above the target range, especially accounts above 5x
+  the target max or above 100k followers when the target range is 8k-20k.
+- Do not automatically reject large-account posts; they can still teach body
+  structure, topic heat, or category language. Do not treat them as primary hook
+  proof unless they also overperform their creator baseline.
+- Large-account hooks can be selected only when the hook carries without the
+  creator: the rendered mobile opening is strong, the premise is reusable by the
+  user, the body pattern does not depend on celebrity authority, and the source
+  either beats baseline or has unusually high reach-adjusted quality after the
+  penalty.
+- Do not overvalue tiny-account anomalies. Very high engagement per follower
+  with low absolute engagement is interesting but lower confidence.
+- When follower data is unavailable, do not invent it. Mark
+  `follower_count_unavailable`, lower confidence, and rely more on creator repeat
+  evidence, repost/share strength, comment quality, and rendered preview quality.
+- A source hook is strongest when it is in/near the target follower band, has
+  real absolute engagement, beats the creator's apparent baseline, has
+  share/comment quality, and passes rendered mobile preview.
+
+Final hook selection must explain both:
+
+- `whyTheHookCarries`: the visible words, specificity, tension, and first-screen
+  promise that work independent of reach
+- `whyTheReachEvidenceIsTrustworthy`: follower-band fit, reach-adjusted score,
+  baseline lift, share/comment quality, or why a large-account example is only
+  secondary pattern evidence
+
 Penalize lead-magnet and engagement-bait mechanics unless the user explicitly asks for that style:
 
 - `comment "template"` / `comment "guide"` / `comment "playbook"`
@@ -198,24 +341,48 @@ Measure the visible opening for every shortlisted source post before extracting
 the hook pattern. This makes the study useful for LinkedIn, not just generally
 "good writing."
 
-LinkedIn does not publish exact "see more" cutoff rules. Treat these as
-conservative v1 planning budgets:
+Use `references/linkedin-preview-rendering.md`. LinkedIn does not publish exact
+"see more" cutoff rules. Character counts are diagnostics only. A source post
+or generated hook is not properly studied until it has a rendered mobile and
+desktop preview record.
+
+Default deterministic renderer for unpublished drafts and research comparison:
 
-- `pass`: opening hook is <= 110 chars including newlines, every nonblank line
-  is <= 45 chars, and the hook's core point lands before likely truncation.
-- `warn`: opening hook is 111-140 chars including newlines, any nonblank line is
-  46-55 chars, or blank lines create visual-line risk. Blank lines are allowed,
-  but they count as physical lines.
-- `fail`: opening hook is > 140 chars including newlines, any nonblank line is
-  > 55 chars, or the hook's core point depends on text after likely truncation.
+```text
+cssContractVersion: linkedin-preview-rendering/v1
+font size: 14px
+line height: 21px
+white space: pre-wrap
+overflow wrap: break-word
+mobile text width: 308px
+desktop text width: 582px
+review clamp: first 3 rendered text lines
+```
 
-Desktop preview has more room, so record it separately, but never let desktop
-fit compensate for a mobile `fail`.
+Authenticated LinkedIn feed/composer screenshots are stronger evidence when
+available. If a screenshot is used, still record the wrapped lines and verdicts
+below so another agent can compare hooks without re-opening LinkedIn.
+
+Desktop preview has more room, but never let desktop fit compensate for a
+mobile `fail`.
 
 For each source, record:
 
 - `sourceTextBasis`: `full_text`, `search_preview`, or `manual_user_source`
 - `openingTextUsed`
+- `renderedPreview`
+- `cssContractVersion`
+- `mobileRenderedPreviewBlock`
+- `desktopRenderedPreviewBlock`
+- `mobileRenderedLines`
+- `desktopRenderedLines`
+- `mobileRenderedLineCount`
+- `desktopRenderedLineCount`
+- `corePainProofOrCuriosityVisibleMobile`
+- `corePainProofOrCuriosityVisibleDesktop`
+- `corePointVisibleMobile`
+- `corePointVisibleDesktop`
+- `pointAfterMobileClamp`
 - `charCountIncludingNewlines`
 - `physicalLineCount`
 - `contentLineCount`
@@ -228,11 +395,25 @@ For each source, record:
 - `desktopPreviewBudget`: `pass`, `warn`, or `fail`
 - `blankLineVisualRisk`
 - `corePointBeforeLikelyTruncation`
+- `renderedPreviewVerdict`: `pass`, `warn`, or `fail`
 
 If only a search preview is available, do not pretend the opening is complete.
 Record `sourceTextBasis: search_preview` and lower confidence when the hook
 appears cut off or body context is unavailable.
 
+Pass/warn/fail is based on rendered output:
+
+- `pass`: the mobile rendered preview shows the pain, proof, or curiosity by
+  the end of the first 3 rendered lines, and the core point is understandable
+  without opening "see more".
+- `warn`: the mobile rendered preview creates useful curiosity but the core
+  point is slightly softened by wrapping, blank-line rhythm, or one missing
+  context word. A compact fallback is required.
+- `fail`: the hook's real point appears after the first 3 mobile rendered
+  lines, the first rendered line is generic setup, blank lines consume the
+  preview before the reader sees the point, or desktop fit is the only reason it
+  looks good.
+
 ## Hook Extraction
 
 Extract structure and reusable language patterns, not copied prose. The goal is
@@ -245,10 +426,13 @@ For each shortlisted source post, record:
 - URL
 - author
 - author profile URL when available
+- author follower count and follower-band fit when available
 - engagement totals and available likes/comments/shares breakdown
+- reach-normalized metrics: engagement per 1k followers, weighted engagement
+  per 1k followers, reach-adjusted score, baseline lift, and confidence
 - creator repeat evidence
 - visible hook text or preview
-- opening preview measurement fields from the section above
+- rendered preview fields from the section above
 - hook mechanism
 - exact hook language patterns: reusable words, phrase shapes, contrast forms,
   sentence shapes, and transition moves
@@ -258,10 +442,16 @@ For each shortlisted source post, record:
 - proof/story dependency
 - lead magnet or engagement bait penalty
 - weighted signal notes
+- reach-normalized signal notes
 - replicability score
 - track person recommendation: `yes`, `no`, or `ask_user`
 - tracking reason when recommended
 
+Do not call a source hook a keeper because the full text is strong if the
+rendered mobile opening is weak. Study what a LinkedIn reader sees before
+"see more"; the body structure can still be useful, but the hook should not be
+copied into the hook pattern set.
+
 ## Specific Language Extraction
 
 For each keeper, extract the source's specific language mechanics in this

package/skills/create-post/references/linkedin-preview-rendering.md

@@ -0,0 +1,163 @@
+# LinkedIn Preview Rendering
+
+This asset defines the required rendered-preview contract for create-post hook
+research, hook candidate generation, gold-standard decomposition, and draft
+validation.
+
+Character budgets are only diagnostics. They are not the preview gate. A hook is
+not studied, selected, or ready until it has been rendered through this contract
+or through a stricter authenticated LinkedIn screenshot.
+
+## Rendering Basis
+
+LinkedIn does not publish exact feed truncation rules, and rendering can vary by
+surface, app version, device, media attachment, and account state. Use this
+deterministic renderer as the MCP review gate for unpublished drafts.
+
+When an authenticated LinkedIn feed/composer/browser screenshot is available,
+that screenshot is the strongest evidence. Still record the fields below so
+future agents can compare candidates without redoing the visual inspection.
+
+Observed public LinkedIn post text style for feed-style post pages:
+
+```text
+selector basis: p.attributed-text-segment-list__content
+font family: -apple-system, system-ui, "Segoe UI", Roboto, "Helvetica Neue",
+  "Fira Sans", Ubuntu, "Oxygen Sans", Cantarell, "Droid Sans",
+  "Lucida Grande", Helvetica, Arial, sans-serif
+font size: 14px
+line height: 21px
+font weight: 400
+letter spacing: normal
+white space: pre-wrap
+overflow wrap: break-word
+text color: rgba(0, 0, 0, 0.9)
+mobile text width: 308px
+desktop text width: 582px
+review clamp: first 3 rendered text lines
+```
+
+The `review clamp` is not an official LinkedIn rule. It is the conservative
+apples-to-apples region create-post must use when comparing hooks. Do not let a
+desktop pass rescue a mobile fail.
+
+## Required Rendering Record
+
+Every shortlisted source hook, adapted hook block, generated hook candidate, and
+selected hook must include a `renderedPreview` record:
+
+```text
+renderedPreview:
+  basis: linkedin_css_contract | authenticated_linkedin_screenshot | manual_user_source
+  cssContractVersion: linkedin-preview-rendering/v1
+  mobile:
+    textWidthPx: 308
+    fontSizePx: 14
+    lineHeightPx: 21
+    visibleTextBlock: <literal first rendered review-clamp block>
+    renderedLines:
+      - <line 1 exactly as wrapped>
+      - <line 2 exactly as wrapped>
+      - <line 3 exactly as wrapped>
+    lineCountBeforeClamp: <number>
+    blankLinesBeforeClamp: <number>
+    corePainProofOrCuriosityVisible: true | false
+    corePointVisible: true | false
+    seeMoreRisk: pass | warn | fail
+    screenshotPath: <optional local path>
+  desktop:
+    textWidthPx: 582
+    fontSizePx: 14
+    lineHeightPx: 21
+    visibleTextBlock: <literal first rendered review-clamp block>
+    renderedLines:
+      - <line 1 exactly as wrapped>
+      - <line 2 exactly as wrapped>
+      - <line 3 exactly as wrapped>
+    lineCountBeforeClamp: <number>
+    blankLinesBeforeClamp: <number>
+    corePainProofOrCuriosityVisible: true | false
+    corePointVisible: true | false
+    seeMoreRisk: pass | warn | fail
+    screenshotPath: <optional local path>
+  diagnostics:
+    charCount: <number>
+    charCountIncludingNewlines: <number>
+    firstLineChars: <number>
+    firstTwoPhysicalLinesChars: <number>
+    longestNonblankLineChars: <number>
+    blankLineVisualRisk: none | low | medium | high
+    pointAfterMobileClamp: true | false
+    rewriteIfTruncated: <short fallback>
+```
+
+If a host cannot produce screenshots, it must still produce the literal wrapped
+line blocks using the CSS contract. If it cannot produce either screenshots or
+literal line wraps, return `blocked` or `needs_revision`; do not claim the hook
+passed preview validation from character counts alone.
+
+## Study Rules
+
+For source-post research:
+
+- Render the exact visible opening from full text when full text is available.
+- If only a search preview is available, render only the preview text and set
+  `basis: manual_user_source` or record `sourceTextBasis: search_preview`.
+- Lower confidence when the search preview is cut off or the body is
+  unavailable.
+- Extract hook lessons from the rendered first-screen experience, not from the
+  full post in isolation.
+
+For generated hooks:
+
+- Generate the hook from the selected premise first.
+- Render the hook for mobile and desktop before scoring it.
+- Score the rendered first-screen promise before scoring cleverness.
+- Rewrite any candidate whose real point appears after the mobile clamp.
+
+## Pass, Warn, Fail
+
+Use these rendered gates:
+
+- `pass`: the mobile rendered preview shows the pain, proof, or curiosity by the
+  end of the first 3 rendered lines, and the core point is understandable
+  without opening "see more".
+- `warn`: the mobile rendered preview creates useful curiosity but the core
+  point is slightly softened by wrapping, blank-line rhythm, or one missing
+  context word. A compact fallback is required.
+- `fail`: the hook's real point appears after the first 3 mobile rendered lines,
+  the first rendered line is generic setup, blank lines consume the preview
+  before the reader sees the point, or desktop fit is the only reason it looks
+  good.
+
+A draft cannot be `ready` when the selected hook has:
+
+- no `renderedPreview`
+- `mobile.seeMoreRisk: fail`
+- `mobile.corePainProofOrCuriosityVisible: false`
+- `mobile.corePointVisible: false`
+- `pointAfterMobileClamp: true`
+
+## Report Format
+
+Research reports must show rendered preview blocks for the best examples and
+recommended draft directions:
+
+```text
+Rendered preview:
+mobile:
+<line 1>
+<line 2>
+<line 3>
+
+desktop:
+<line 1>
+<line 2>
+<line 3>
+
+verdict: pass | warn | fail
+why: <what is visible before the fold>
+```
+
+Do not say "it fits on mobile" without showing what the mobile reader actually
+sees.

package/skills/create-post/references/post-file-contract.md

@@ -59,10 +59,19 @@ Hook research files must preserve:
 - source post URLs
 - author/profile URLs
 - engagement totals
+- author follower counts when available, target follower band, follower-band
+  fit, engagement per 1k followers, weighted engagement per 1k followers,
+  reach penalty multiplier, reach-adjusted score, baseline lift when available,
+  why the hook carries independent of creator reach, and normalization
+  confidence notes
 - full-text availability
 - source hook preview measurements, including text basis, char count including
   newlines, physical/content line counts, longest nonblank line, blank-line
   visual risk, and mobile/desktop preview budget status
+- rendered preview records for every kept source hook and adapted hook block,
+  including literal mobile/desktop preview blocks, rendered line wraps, render
+  basis, CSS contract version, text widths, first-screen promise visibility,
+  core point visibility, and whether the point lands after the mobile clamp
 - extracted hook patterns
 - selected hook basis
 
@@ -83,6 +92,9 @@ Draft files must preserve:
 - draft body
 - validation receipt, including LinkedIn preview pass/warn/fail status and
   compact fallback when the selected hook carries a warning
+- rendered mobile and desktop preview blocks for the selected hook; drafts
+  cannot be ready when this rendered-preview audit is missing or fails mobile
+  visibility
 - status: `draft`, `ready`, `needs_revision`, `published`, or `archived`
 
 Multiple drafts for the same idea are expected. Keep the `ideaId` stable and

package/skills/create-post/references/post-validation.md

@@ -11,6 +11,7 @@ Every saved draft needs a validation receipt. A draft without this receipt is no
 - `candidateHooksConsidered`
 - `selectedHook`
 - `selectedHookWhy`
+- `sourceHookReachAudit`
 - `proofClaimsUsed`
 - `proofClaimSources`
 - `storyFilesConsulted`
@@ -77,7 +78,17 @@ Each candidate should include:
 - premise tension opened
 - reader value implied
 - source pattern
+- source pattern reach signals: author follower count when available, target
+  follower band, follower-band fit, engagement per 1k followers, weighted
+  engagement per 1k followers, reach-adjusted score, baseline lift, and
+  confidence
 - score
+- `renderedPreview` using `references/linkedin-preview-rendering.md`
+- literal mobile and desktop rendered preview blocks
+- mobile and desktop rendered line wraps
+- first-screen promise: pain, proof, or curiosity visible by the mobile clamp
+- whether the core point is visible in the mobile rendered preview
+- whether the point lands after the mobile clamp
 - char count including newlines and first-line / first-two-line preview measurements
 - physical line count, content line count, longest nonblank line, and blank-line risk
 - `previewBudgetStatus`: `pass`, `warn`, or `fail`
@@ -98,7 +109,7 @@ After the first draft:
 6. replace generic language with concrete words only when supported
 7. preserve the user's actual story and point
 8. remove AI tells
-9. re-check LinkedIn preview fit after edits
+9. re-render the selected hook on mobile and desktop after edits
 
 ## Premise Value Audit
 
@@ -147,24 +158,96 @@ If `selectedControversy` is missing, if the audience belief is only a generic
 label like "founders want growth," or if `credibleWhyUs` depends on borrowed
 proof from another creator, save as `needs_revision`.
 
-## LinkedIn Preview Audit
+## Source Hook Reach Audit
 
-Audit the selected hook and top candidates against conservative LinkedIn
-preview budgets. LinkedIn does not publish exact "see more" cutoff rules, and
-rendering varies by device, app version, font, media, and line break. This audit
-is a mobile-first safety gate, not a claim about an official LinkedIn limit.
+Before a draft can be `ready`, validate that the selected source hook pattern
+was chosen for a reach-normalized reason, not raw audience size.
 
-Use:
+Record:
+
+- `targetFollowerBand`
+- `authorFollowerCount` for each source pattern when available
+- `followerBandFit`: `in_target_band`, `below_target_band`,
+  `above_target_band`, or `unknown`
+- `engagementPer1kFollowers`
+- `weightedEngagementPer1kFollowers`
+- `reachAdjustedScore`
+- `reachPenaltyMultiplier`
+- `creatorBaselineMedianEngagement` or `creator_baseline_unavailable`
+- `baselineLift` or `creator_baseline_unavailable`
+- `bigAccountPenaltyApplied`
+- `whyTheHookCarries`
+- `followerCountUnavailableSources`
+- `whyThisHookIsAReachAdjustedSignal`
+
+If the user asked for a follower range and the selected source pattern is from a
+large account above the target range, the receipt must explain why it survived
+the celebrity reach penalty. Use large-account hooks as secondary pattern
+evidence unless they clearly overperform the creator's baseline or the hook
+itself carries after reach is controlled. A draft cannot be `ready` when the
+selected hook is justified only by raw total engagement or follower count.
+
+## LinkedIn Preview Audit
 
-- `pass`: hook is <= 110 chars including newlines, every nonblank line is <= 45 chars, and the hook's core point lands before likely truncation.
-- `warn`: hook is 111-140 chars including newlines, any nonblank line is 46-55 chars, or blank lines create visual-line risk. Blank lines are allowed, but they count as physical lines.
-- `fail`: hook is > 140 chars including newlines, any nonblank line is > 55 chars, or the hook's point depends on text after likely truncation.
+Audit the selected hook and top candidates against
+`references/linkedin-preview-rendering.md`. LinkedIn does not publish exact
+"see more" cutoff rules, and rendering varies by device, app version, font,
+media, and line break. This audit is a mobile-first rendered-preview safety
+gate, not a claim about an official LinkedIn limit.
+
+Character budgets are secondary diagnostics. They cannot be the only evidence
+that a hook works. Every selected hook must include literal rendered mobile and
+desktop preview blocks.
+
+Default deterministic renderer when no authenticated LinkedIn screenshot is
+available:
+
+```text
+cssContractVersion: linkedin-preview-rendering/v1
+font size: 14px
+line height: 21px
+white space: pre-wrap
+overflow wrap: break-word
+mobile text width: 308px
+desktop text width: 582px
+review clamp: first 3 rendered text lines
+```
+
+Use rendered gates:
+
+- `pass`: the mobile rendered preview shows the pain, proof, or curiosity by
+  the end of the first 3 rendered lines, and the core point is understandable
+  without opening "see more".
+- `warn`: the mobile rendered preview creates useful curiosity but the core
+  point is slightly softened by wrapping, blank-line rhythm, or one missing
+  context word. A compact fallback is required.
+- `fail`: the hook's real point appears after the first 3 mobile rendered
+  lines, the first rendered line is generic setup, blank lines consume the
+  preview before the reader sees the point, or desktop fit is the only reason it
+  looks good.
 
 Desktop preview usually has more room. Still record desktop fit, but never let
 desktop fit compensate for a mobile `fail`.
 
 Record:
 
+- `renderedPreview`
+- `renderBasis`: `linkedin_css_contract`, `authenticated_linkedin_screenshot`,
+  or `manual_user_source`
+- `cssContractVersion`
+- `mobileRenderedPreviewBlock`
+- `desktopRenderedPreviewBlock`
+- `mobileRenderedLines`
+- `desktopRenderedLines`
+- `mobileTextWidthPx`
+- `desktopTextWidthPx`
+- `mobileRenderedLineCount`
+- `desktopRenderedLineCount`
+- `corePainProofOrCuriosityVisibleMobile`
+- `corePainProofOrCuriosityVisibleDesktop`
+- `corePointVisibleMobile`
+- `corePointVisibleDesktop`
+- `pointAfterMobileClamp`
 - `charCount`
 - `charCountIncludingNewlines`
 - `firstLineChars`
@@ -183,10 +266,14 @@ Record:
 - `rewriteIfTruncated`
 - `compactFallback` when `previewBudgetStatus` is `warn`
 
-If the hook only works after likely truncation, rewrite it. A draft cannot be
-`ready` with `previewBudgetStatus: fail`. A draft may be `ready` with
-`previewBudgetStatus: warn` only when the warning is explicit, usually because
-the user prefers blank-line rhythm, and the receipt includes a compact fallback.
+If the hook only works after the rendered mobile clamp, rewrite it. A draft
+cannot be `ready` with `previewBudgetStatus: fail`,
+`mobilePreviewFit: fail`, missing `renderedPreview`,
+`corePainProofOrCuriosityVisibleMobile: false`,
+`corePointVisibleMobile: false`, or `pointAfterMobileClamp: true`. A draft may
+be `ready` with `previewBudgetStatus: warn` only when the warning is explicit,
+usually because the user prefers blank-line rhythm, and the receipt includes a
+compact fallback.
 
 ## Simplifier / Concrete-Language Audit