mustflow 2.116.4 → 2.117.1

package/templates/default/locales/en/.mustflow/skills/game-liveops-commerce-integrity-review/SKILL.md

@@ -0,0 +1,237 @@
+---
+mustflow_doc: skill.game-liveops-commerce-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: game-liveops-commerce-integrity-review
+description: Apply this skill when a game changes seasonal battle passes, monthly memberships, live-operations cadence, missions and reward tracks, cosmetic or power goods, convenience and sidegrades, deterministic bundles, paid or free randomized rewards, loot boxes, odds and pity disclosure, duplicate protection, purchase concentration, content-production cost, fairness, player retention, platform review, or regulatory risk and must sustain revenue without creating an unaffordable content treadmill, paid hierarchy, or opaque random-spend system.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.game-liveops-commerce-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Game Liveops Commerce Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose season, membership, catalog, power, and random-reward policy from sustainable production,
+fairness, retained play, and long-horizon contribution. Prevent a small team from financing short-
+term revenue with permanent content debt, recurring-value debt, pay-to-win escalation, concentrated
+random spend, platform rejection, or regulatory and support burden.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A game chooses or changes a seasonal battle pass, free and premium reward track, monthly
+  membership, VIP subscription, recurring liveops cadence, mission schedule, or retroactive progress.
+- The catalog sells cosmetics, characters, weapons, stats, progression, convenience, sidegrades,
+  presets, slots, storage, automation, ad removal, or other gameplay-affecting benefits.
+- A product compares deterministic bundles with paid or free randomized rewards, loot boxes, gacha,
+  choice packs, duplicate protection, pity, exchange tokens, odds, or spend limits.
+- A report compares conversion, payer count, ARPPU, whale concentration, content-production cost,
+  balance cost, support, refunds, regulation, retention, fairness, or long-horizon contribution.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is death, revive, lives, energy, natural recovery, refill, rewarded-ad recovery,
+  unlimited play, or failure monetization; use `game-economy-monetization-review`.
+- The task only changes generic subscription price, annual billing, regional pricing, trial, or
+  cancellation; use pricing, payment, and subscription-retention skills.
+- The task only changes credit balance rights, virtual-currency expiry, quote, reserve, capture,
+  release, reversal, or spend order; use the credit monetization and ledger skills.
+- The main risk is cryptographic random generation, draw atomicity, inventory concurrency,
+  entitlement delivery, payment callbacks, refunds, fraud, or audit-log tamper resistance. Use the
+  matching randomness, transaction, entitlement, payment, and security owners.
+- The task requests jurisdiction-specific gambling, consumer, child-safety, tax, accounting, or
+  marketing advice. Use current qualified authority; this skill prepares the product evidence.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Team-capacity ledger: available disciplines, person-time, asset pipeline, reuse limits,
+  localization, QA, economy balancing, community, support, compliance, release cadence, and buffer.
+- Season ledger: duration, tiers, free and paid tracks, price, missions, catch-up, late purchase,
+  retroactive grant, asset and currency rewards, production cost, completion, next-season rebate,
+  refunds, and content debt.
+- Membership ledger: period, ongoing feature and content value, renewal, benefits, device access,
+  production and support cost, cancellation, refund, IAP cannibalization, and retained subscribers.
+- Catalog ledger: item, deterministic contents, cosmetic visibility, asset lineage, power or
+  convenience effect, acquisition path, price, version, obsolescence, balance cost, and content burn.
+- Random-reward ledger: free or paid access, direct or virtual-currency consideration, pool, odds,
+  rarity, duplicate behavior, pity or guarantee, exchange, history, version, cap, age, geography,
+  refund, withdrawal, platform, and jurisdiction evidence.
+- Economics ledger: eligible-player conversion, payer count, revenue distribution, net revenue,
+  production, platform, support, balance, compliance, refund, dispute, fraud, and variable cost;
+  retention, content completion, fairness, and contribution.
+- Experiment ledger: pre-offer assignment, season and catalog versions, player and payer strata,
+  holdout, traffic, horizon, delayed outcomes, guardrails, and promotion rule.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate cadence product, item type, gameplay power, and reward randomness. A season pass can sell
+  deterministic cosmetics; a membership can exist without new monthly assets; randomness is another
+  axis.
+- Define the team's sustainable production and review capacity before promising a season or recurring
+  content cadence.
+- Define the highest fair competitive and progression boundary before selling power or convenience.
+- Refresh current store, platform, age-rating, odds-disclosure, virtual-currency, refund, child,
+  gambling, consumer, and jurisdiction rules before implementing paid random rewards.
+- Treat copied season lengths, tier counts, prices, asset counts, renewal rates, production months,
+  odds, pity counts, spend caps, and benchmark concentration as hypotheses, not defaults.
+- This skill does not authorize live catalog, price, currency, draw, reward, experiment, payment,
+  message, release, or production changes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine season and membership policy, missions and catch-up, catalog classification,
+  cosmetic visibility, power and sidegrade limits, deterministic contents, random-reward disclosures,
+  pity and duplicates, caps, contribution metrics, experiments, fixtures, tests, docs, route metadata,
+  and synchronized templates.
+- Replace unsustainable cadence, daily-attendance punishment, permanent paid power, undisclosed
+  random contents, opaque virtual-currency cost, or concentrated random-spend optimization with
+  bounded, transparent alternatives.
+- Do not present a paid random mechanism as safe merely because odds are disclosed, or a cosmetic as
+  harmless when it changes visibility, targeting, hitboxes, accessibility, or competitive clarity.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split four decisions: recurring cadence, catalog contents, gameplay advantage, and randomness.
+   Do not make battle pass, membership, cosmetic, power, bundle, and loot box one binary comparison.
+2. Start with production capacity. Price design, art, animation, audio, mission writing, economy,
+   localization, QA, release, community, support, and compliance work, including interruption and
+   rework. Revenue does not make an impossible calendar sustainable.
+3. Treat a season pass as a dated content and progression obligation. Define duration, tiers,
+   missions, asset reuse, free track, premium track, completion expectation, late entry, catch-up,
+   retroactive rewards, post-season handling, and next-season transition.
+4. Derive season length and tier count from player cadence and team throughput. A familiar week count
+   or hundred-tier template is not a default. Preserve schedule buffer for defects and unplanned
+   liveops work.
+5. Avoid attendance punishment. Prefer accumulable or catch-up missions where they fit the loop,
+   distinguish engagement from daily coercion, and let late buyers understand and receive already
+   earned premium-track value according to the declared contract.
+6. Price currency returned by the pass as future liability and cannibalization. Model how many
+   players can fund later passes without new cash, what else the currency buys, and whether the
+   design creates an indefinite one-purchase entitlement unintentionally.
+7. Treat membership as an ongoing-value obligation. Define durable feature value, convenience,
+   service, multiplayer, storage, creation, support, ad treatment, or recurring content that exists
+   every billing period. Predictable billing is not predictable retention.
+8. Compare season and membership economics over the same horizon. Include initial development,
+   recurring production, platform fees, refunds, support, cancellation, renewal, IAP displacement,
+   content reuse, missed cadence, and retained contribution per eligible player.
+9. Prefer membership when ongoing low-marginal-cost value remains useful without a new asset factory;
+   prefer seasons when repeat play can support a bounded reward-and-mission cadence. Treat both as
+   candidates and allow coexistence only when benefits and obligations do not double-charge value.
+10. Classify every catalog item as cosmetic, convenience, sidegrade, progression acceleration,
+    direct power, content access, currency, or mixed. Review mixed items by their strongest gameplay
+    and legal consequence rather than their marketing label.
+11. Make cosmetics visible and valuable without harming play. Identify lobby, profile, social,
+    cooperative, replay, photo, emote, entrance, victory, audio, or collection surfaces, while
+    preserving readability, accessibility, hitbox, silhouette, team, and competitive clarity.
+12. Track asset economics. Record original production cost, skeleton and material reuse, variants,
+    exclusivity, resale promises, approval, and expected sales. Reuse should lower cost without
+    misrepresenting a trivial recolor as a wholly new premium asset.
+13. Preserve the fair ceiling. Avoid paid exclusive maximum power or direct competitive superiority.
+    Evaluate sidegrades, presets, storage, queues, respec, convenience, and bounded acceleration by
+    whether nonpayers can reach the same fair endpoint and whether seasonal competition resets or
+    matchmaking neutralizes the advantage.
+14. Price PvE power by content burn and future balance debt. Track skipped mastery, faster completion,
+    obsolete encounters, support, inflation, and pressure to sell a stronger successor. Low art cost
+    does not make permanent power cheap to operate.
+15. Prefer deterministic purchase contents when broad payer trust, understandable value, stable
+    conversion, refund simplicity, and low compliance load matter. Show every item, quantity,
+    duplicate rule, currency value, time limit, and entitlement before purchase.
+16. Treat paid random rewards as a separate high-risk product. Map every way money or purchased
+    currency reaches the draw. Record pool, odds, rarity, duplicates, pity, guarantees, exchange,
+    history, versions, spend distribution, age, geography, and applicable current authority.
+17. Do not infer safety from disclosure. Odds can satisfy one platform requirement while fairness,
+    children, consumer vulnerability, price transparency, withdrawal, gambling, and jurisdiction
+    issues remain unresolved.
+18. Keep competitive power out of paid randomness unless current authority and a separately approved
+    fairness contract explicitly support it. Prefer deterministic access, earnable sidegrades, or
+    noncompetitive cosmetics when uncertainty would compound pay-to-win harm.
+19. Separate free randomness from paid randomness, but inspect indirect consideration. Ads,
+    purchased energy, paid keys, premium-only attempts, or currency conversion can make a nominally
+    free draw economically connected to payment.
+20. If randomness is retained, make draw execution and history auditable. Version odds and pools,
+    snapshot eligibility, use authoritative server results, define duplicate and pity transitions,
+    preserve user-visible progress, cap retries and spend where required, and route technical
+    integrity to transaction and randomness owners.
+21. Measure payer distribution, not only averages. Track payer conversion, median and tail spend,
+    revenue concentration, repeated purchase, refunds, disputes, support, regret, age and geography,
+    item ownership, retained play, and contribution. A few extreme spenders can hide a shrinking
+    payer base and material harm.
+22. Preserve non-purchase acquisition paths and catalog history. State whether items return, rotate,
+    become earnable, remain exclusive, or change strength; do not use fake scarcity or silently
+    devalue previously purchased items.
+23. Sequence experiments when traffic is limited. Resolve cadence sustainability before tuning
+    prices, cosmetic visibility before multiplying assets, and deterministic value before testing
+    randomness. Keep mechanics isolated enough to identify the source of lift or harm.
+24. Promote only a reversible, versioned commerce policy that improves eligible-player contribution
+    without exceeding production capacity, damaging fair play, hiding price or contents, depending
+    on harmful spend concentration, or violating current platform and legal authority.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Season and membership obligations have explicit production, value, cadence, renewal, and
+  cannibalization economics.
+- Catalog items have a truthful cosmetic, convenience, sidegrade, acceleration, power, content, or
+  currency classification and a fair-ceiling decision.
+- Deterministic bundles disclose complete value; paid random rewards have separate authority,
+  probability, pity, duplicate, spend, audit, age, geography, and harm evidence.
+- Free randomness is checked for indirect paid access rather than assumed outside commerce rules.
+- Headline economics include team capacity, content and balance debt, payer distribution, refunds,
+  compliance, retained play, fairness, and long-horizon contribution.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer live store, catalog, price, currency, draw, payment, analytics, experiment, release,
+deployment, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If sustainable production capacity is unknown, do not promise a fixed recurring content cadence.
+- If membership has no ongoing value beyond monthly asset production, compare it as a content
+  obligation rather than claiming low-cost recurring revenue.
+- If an item changes competitive power but lacks a fair-ceiling contract, keep it out of sale.
+- If paid-random authority, odds, pool versions, pity, duplicates, age, or geography cannot be
+  reconstructed, stop new paid draws and prefer deterministic sale or non-purchasable rewards.
+- If revenue rises only through extreme payer concentration while payer breadth, refunds, support,
+  fairness, or retained contribution worsens, reject or narrow the mechanism.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Team capacity, liveops cadence, production buffer, and content obligation
+- Season duration, tiers, missions, catch-up, late purchase, rewards, rebate, and economics
+- Membership ongoing value, renewal, production, IAP displacement, and contribution
+- Catalog classification, cosmetic visibility, asset reuse, fair ceiling, power, and content burn
+- Deterministic contents or paid/free randomness, odds, pity, duplicates, cap, age, and geography
+- Payer breadth, spend concentration, refunds, support, fairness, retention, and authority evidence
+- Files changed
+- Command intents run and skipped checks
+- Remaining game-liveops commerce risk
+

package/templates/default/locales/en/.mustflow/skills/growth-distribution-integrity-review/SKILL.md

@@ -0,0 +1,247 @@
+---
+mustflow_doc: skill.growth-distribution-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: growth-distribution-integrity-review
+description: Apply this skill when a product changes free-result watermarking or embedded attribution, public-share branding, affiliate or influencer compensation, partner attribution and clawbacks, recurring or lifetime commission, owned-product cross-promotion, portfolio promotion frequency, brand relationship disclosure, incremental acquisition, channel cannibalization, or retained portfolio contribution and must grow distribution without degrading the result users share, paying for natural demand, confusing product identity, or damaging the source product.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.growth-distribution-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Growth Distribution Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Review embedded result attribution, commercial partners, and owned-product cross-promotion as
+different distribution mechanisms with one economic standard: incremental retained contribution
+after source-product harm, partner cost, fraud, support, privacy, and brand confusion. Do not turn
+useful output into an ad, grant perpetual commission for nonincremental demand, or call internal
+inventory free when it damages the product that owns the user relationship.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A free result adds, removes, resizes, relocates, or gates a visible service name, watermark, footer,
+  end card, attribution link, metadata mark, removal entitlement, or branded export.
+- A product recruits influencers, creators, affiliates, comparison publishers, agencies, resellers,
+  integration partners, or other commercial acquisition partners and changes fixed fees, CPA,
+  first-payment share, recurring commission, lifetime commission, attribution, or clawbacks.
+- One owned service recommends another through a dashboard, success screen, result surface, account
+  hub, email, notification, modal, interstitial, or contextual next step.
+- A report compares organic acquisition, affiliate CAC, external paid acquisition, cross-promotion,
+  brand lift, portfolio revenue, fatigue, cannibalization, or retained contribution.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task is a customer-to-customer referral reward, invite code, dual-sided incentive, reward tier,
+  valid-referral event, or self-referral control; use
+  `referral-incentive-integrity-review`.
+- The task is a paid ad or rewarded-ad placement inside a free tier, result gate, ad SDK, premium ad
+  removal, or ad-funded access decision; use `freemium-ad-monetization-review`.
+- The task only changes trademark ownership, generic visual identity, SEO, ad creative, marketing
+  copy, public-relations messaging, or analytics implementation with no distribution policy; use the
+  narrower brand, content, attribution, privacy, security, or data procedure.
+- The task requests jurisdiction-specific affiliate, advertising, tax, contract, privacy, or AI
+  marking advice. Use current qualified authority; this skill supplies the product evidence packet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Artifact ledger: result type, ownership, public or private use, export path, share rate, recipient
+  reach, attribution visibility and persistence, placement, removal, editability, accessibility,
+  quality, privacy, professional-use risk, and AI-origin or provenance requirement.
+- Partner ledger: partner identity and type, audience, channel, content lifetime, claimed reach,
+  attribution window and priority, click, signup, qualification, payment, refund, chargeback,
+  retained revenue, commission, cap, duration, termination, clawback, disclosure, approval, brand
+  safety, prohibited claim, support, tax, contract, and jurisdiction review.
+- Cross-promotion ledger: source and target product, user and job adjacency, product relationship,
+  placement, success state, eligibility, exposure sequence, frequency, suppression, account and data
+  continuity, consent, external-acquisition alternative, and source-product opportunity cost.
+- Causal ledger: pre-exposure assignment, persistent holdout, natural discovery, existing intent,
+  channel overlap, incremental activation and payment, retained contribution, cannibalization,
+  source-product completion and retention, complaints, hides, unsubscribes, and brand-understanding.
+- Economics ledger: partner and creative cost, net revenue, variable service and payment cost,
+  refund, chargeback, support, fraud, commission liability, source-product lost value, external CAC,
+  portfolio contribution, horizon, and uncertainty.
+- Version ledger: artifact policy, campaign, partner contract, attribution rule, disclosure, source
+  and target eligibility, frequency, suppression, experiment, and current authority version.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate embedded attribution, partner compensation, and owned cross-promotion. A shared growth
+  goal does not make their rights, risks, or attribution rules interchangeable.
+- Define the source product's completed value and the incremental target outcome before adding a
+  brand mark, partner payment, or cross-promotion exposure.
+- Assign experiments before the mark or promotion is visible where feasible, and preserve eligible
+  nonsharers, nonclickers, nonbuyers, and source-product abandoners in the relevant denominator.
+- Treat copied watermark sizes, share rates, commission percentages, attribution windows, lifetime
+  terms, exposure counts, fit scores, CAC, and conversion thresholds as hypotheses, not defaults.
+- Refresh current endorsement, advertising, consumer, privacy, accessibility, platform, tax,
+  contract, trademark, and AI-origin marking rules for the relevant role, content, channel,
+  geography, and date.
+- This skill does not authorize live marks, partner recruitment, contracts, payments, tracking,
+  cross-product data sharing, campaigns, experiments, messages, or production changes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine artifact branding eligibility, placement and removal, share and recipient events,
+  partner qualification and compensation, attribution, disclosure, fraud and clawback controls,
+  cross-promotion eligibility and suppression, relationship explanations, experiment assignment,
+  contribution metrics, fixtures, tests, docs, route metadata, and synchronized templates.
+- Replace universal watermarking, gross attributed revenue, last-click poaching, uncapped lifetime
+  commission, source-product interruption, or raw cross-product clicks with bounded rights and
+  causal portfolio economics.
+- Do not insert private identifiers or covert user tracking into exported artifacts, misrepresent
+  authorship, suppress required disclosure, transfer account data without authority, or impair the
+  result users completed merely to make brand removal a paid feature.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split the review into artifact attribution, partner compensation, and owned cross-promotion.
+   Evaluate each independently before comparing their contribution as acquisition channels.
+2. Define the headline result as incremental retained contribution per eligible source user or
+   acquisition opportunity over a declared horizon. Include target revenue and service cost,
+   partner cost, refunds, disputes, fraud, support, source-product lost value, and cannibalization.
+3. Classify the artifact. Estimate whether it is privately stored, internally circulated, sent to a
+   small known group, published repeatedly, or distributed to a broad public audience.
+   Do not infer reach from export count alone.
+4. Build the artifact acquisition path from created result to external share, unique recipient,
+   visible attribution, attributable visit, activated user, payer, and retained contribution. Keep
+   original-user conversion and retention loss in the same calculation.
+5. Use visible branding only when attribution can survive a real public distribution path and its
+   incremental value exceeds quality, sharing, conversion, accessibility, privacy, and support harm.
+   A watermark on a private or low-reach artifact is not a growth engine by default.
+6. Preserve the completed result. Keep branding outside critical content where possible, readable
+   but not dominant, accessible, and compatible with professional use. Never obscure evidence,
+   damage legibility, imply false authorship, or block export solely to force removal payment.
+7. Choose the least harmful attribution carrier that can work. A small footer, end card, adjacent
+   share link, or approved metadata can be a candidate; visible and machine-readable marks solve
+   different problems and neither proves compliance with every current AI-origin rule.
+8. Do not embed user, recipient, prompt, tenant, or private tracking data in exported files. Define
+   whether attribution survives editing, screenshots, transcoding, printing, and platform stripping,
+   and measure the actual recipient path rather than assumed virality.
+9. Classify the partner's continuing work. Short-lived sponsored reach, durable search or tutorial
+   content, ongoing implementation, reseller support, and customer-success work justify different
+   compensation shapes.
+10. Compare fixed production cost, qualified CPA, first-payment share, and bounded recurring share at
+    equal expected budget and qualification quality. Do not call a higher-spend arm more persuasive
+    without separating spend from contract shape.
+11. Calculate partner economics from incremental customers. Exclude or discount existing demand,
+    branded-search interception, leaked coupons, self-referral, duplicate partners, pre-existing
+    accounts, refund-window purchases, and customers who would have converted through another owned
+    or paid channel.
+12. Bind compensation to a qualified event and net revenue. Version attribution priority, window,
+    product scope, refund and chargeback treatment, tax, currency, minimum payout, cap, termination,
+    inactivity, content removal, and clawback before value vests.
+13. Treat lifetime commission as a long-lived liability, not a free acquisition rate. Use it only
+    when the partner continues to create attributable value or service after acquisition and the
+    agreement has explicit scope, activity, cap or review, termination, transfer, audit, and margin
+    protection. A bounded recurring term is a candidate, not a universal duration.
+14. Make commercial relationships clear and conspicuous near the endorsement or link as required by
+    current authority. Train and monitor partners, preserve content evidence, prohibit unsupported
+    claims, and define brand-safety escalation rather than relying only on a platform disclosure UI.
+15. Prevent attribution abuse with deterministic rules and multiple signals. Cover cookie stuffing,
+    forced redirects, toolbar or extension injection, trademark bidding, last-click poaching,
+    coupon leakage, fake leads, duplicate identities, self-dealing, and partner collusion while
+    preserving review and appeal for legitimate conflicts.
+16. Classify source-target fit before cross-promotion. Use audience overlap, adjacent user job,
+    brand promise, account and data relationship, and target readiness as evidence; ownership by the
+    same operator alone does not make two products relevant.
+17. Deliver the source product's primary value before promotion. Prefer a contextual next step after
+    success or in a clearly separate portfolio surface. Do not interrupt first value, active work,
+    checkout, cancellation, safety, privacy, or accessibility flows.
+18. Explain the relationship honestly. State whether the target is another product, an optional
+    companion, or part of a suite; do not imply shared entitlements, identity, data, support, or
+    warranties that the current contract does not provide.
+19. Make cross-product data movement explicit. Define consent, purpose, tenant and account boundaries,
+    deletion, suppression, and access before transferring user input or state. A click may deep-link
+    without silently provisioning or copying private data.
+20. Derive fatigue from marginal value by exposure sequence. Track incremental activation and target
+    contribution against source completion, retention, hides, complaints, unsubscribes, and support
+    after each exposure. Stop when marginal portfolio value is nonpositive; do not copy a universal
+    session, week, or month cap.
+21. Suppress irrelevant repetition. Stop or cool down after conversion, purchase, explicit rejection,
+    repeated nonresponse, source-product distress, target ineligibility, or relationship mismatch.
+    Keep campaign and suppression versions reconstructable across channels.
+22. Compare owned inventory with external acquisition using opportunity cost. Internal exposure is
+    not free: include source-product lost value, displaced product messages, creative and operations,
+    and portfolio cannibalization alongside the target's external incremental CAC.
+23. Use persistent holdouts where feasible to estimate natural sharing, partner incrementality, cross-
+    product discovery, and source-product damage. Observed clicks, attributed revenue, or users of two
+    products do not prove the channel caused portfolio growth.
+24. Promote only a reversible policy that improves incremental portfolio contribution while
+    preserving useful artifacts, honest commercial disclosure, deterministic attribution, partner
+    quality, source-product value, brand clarity, privacy, accessibility, and current authority.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Artifact attribution, partner compensation, and owned cross-promotion remain distinct contracts.
+- Visible branding is limited to an evidence-backed distribution path and does not degrade or
+  misrepresent the completed result.
+- Partner rewards use deterministic attribution, qualified net value, bounded liability, disclosure,
+  fraud controls, clawbacks, and review.
+- Cross-promotion follows source value, explains product relationships, respects account and data
+  boundaries, suppresses fatigue, and includes source-product opportunity cost.
+- Headline growth uses causal portfolio contribution rather than exports, impressions, clicks,
+  attributed gross revenue, or users observed in multiple products.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and
+`mustflow_check`. Do not infer live export, affiliate, payment, tracking, campaign, analytics,
+cross-product data, messaging, deployment, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If recipient reach, partner qualification, or source-product damage cannot be measured, keep the
+  policy reversible and report association rather than claiming incremental acquisition.
+- If branding reduces utility, accessibility, privacy, sharing, conversion, or professional use more
+  than attributable retained contribution, remove or narrow it instead of optimizing removal sales.
+- If partner attribution cannot exclude existing intent, refunds, self-dealing, or channel overlap,
+  keep compensation pending or cap it under the current contract; do not grant unbounded liability.
+- If commercial disclosure, claim substantiation, tax, contract, or jurisdiction authority is
+  unresolved, do not launch or expand the affected partner treatment.
+- If cross-promotion improves the target while reducing source or portfolio contribution, reject or
+  narrow the placement even when click-through and target revenue rise.
+- If account or data relationships are ambiguous, use a separate optional link and do not transfer
+  identity or private state.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Artifact type, ownership, distribution path, recipient reach, attribution, placement, removal,
+  quality, accessibility, privacy, AI-origin, and contribution decision
+- Partner type, continuing work, qualification, compensation shape, equal-budget comparison,
+  attribution, disclosure, cap, duration, termination, clawback, fraud, and incrementality decision
+- Source and target product fit, relationship, placement, success state, account and data boundary,
+  frequency, suppression, source-product harm, external-CAC comparison, and portfolio decision
+- Experiment assignment, holdout, horizon, natural demand, cannibalization, retained contribution,
+  guardrails, and uncertainty
+- Files changed
+- Command intents run and skipped checks
+- Remaining growth-distribution risk

package/templates/default/locales/en/.mustflow/skills/idempotency-integrity-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.idempotency-integrity-review
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: idempotency-integrity-review
@@ -60,6 +60,9 @@ deduplicates the operation or rejects the stale result?"
 ## Required Inputs
 
 - Operation identity ledger: logical operation, attempt, effect, actor, tenant, target resource, business operation type, canonical payload hash, idempotency key, event ID, message ID, provider object ID, batch key, scheduler run key, and retry source.
+- Workflow identity ledger when plans can change: `workflow_id`, `plan_id` or plan version,
+  `step_id`, stable `effect_id`, per-try `attempt_id`, causation ID, correlation ID, and the rule that
+  decides whether a replan represents the same admitted business intent or a new one.
 - Ordering and authority ledger: aggregate key, ordering scope, observed state, expected state, aggregate version, sequence, generation, fencing token, gap policy, stale-result decision, and authoritative conditional write.
 - Side-effect ledger: every charge, refund, balance change, stock change, coupon issue, shipment, email, notification, entitlement, status transition, file write, queue publish, cache change, provider call, and audit entry.
 - Durable dedupe evidence: unique constraints, idempotency table, inbox table, outbox table, applied event table, ledger source key, conditional update, state guard, provider idempotency key, and response record.
@@ -93,7 +96,11 @@ deduplicates the operation or rejects the stale result?"
 1. Name the logical operation, not only the endpoint.
    - POST, PATCH, DELETE, webhook, queue consumer, scheduler, batch replay, retry wrapper, and callback handlers can all carry the same duplicate-intent risk.
    - Ask what "same intent" means in business terms: same order payment attempt, same refund, same point grant, same coupon redemption, same shipment, same notification, same state transition, same imported row, or same provider event.
-   - Separate the stable operation ID from attempt, message, event, effect, trace, worker, and provider IDs. Generate a new attempt ID for a retry without generating a new business operation.
+   - Separate the stable operation ID from attempt, message, event, effect, trace, worker, and provider IDs. Generate a new `attempt_id` for a retry without generating a new business operation.
+   - In a replanning workflow, keep `workflow_id` stable for the workflow, `step_id` stable for the
+     logical step when appropriate, `effect_id` stable for the same admitted business intent across
+     plan versions, and `attempt_id` new for each execution try. A new plan version is not permission
+     to create a duplicate effect.
 2. Start at the side effect.
    - Find calls and writes named like `charge`, `capture`, `refund`, `withdraw`, `grantPoint`, `deductStock`, `issueCoupon`, `sendEmail`, `createShipment`, `publish`, `ack`, `markPaid`, `fulfill`, and local equivalents.
    - For each side effect, ask what happens if the exact surrounding handler runs twice, runs concurrently, or runs after the first response is lost.
@@ -102,6 +109,12 @@ deduplicates the operation or rejects the stale result?"
    - Duplicate key plus changed amount, resource, user, tenant, product, operation, or payload should become a stable mismatch response, not a new operation or silent old response.
    - Do not accept memory-only stores, process-local maps, or Redis TTL alone for operations that can be retried after restart, failover, delayed callback, or TTL expiry.
    - Keep the operation key stable across request, durable operation record, inbox or outbox, external effect, result lookup, and response replay.
+   - Derive or mint keys at a trusted boundary. Do not place raw personal data, secrets, mutable
+     display names, timestamps, or model-generated prose in a key. Prefer opaque random or keyed
+     deterministic identifiers whose canonical request fingerprint is stored separately.
+   - Retain durable idempotency evidence for at least the longest supported client retry, queue
+     redelivery, delayed callback, workflow recovery, manual replay, and business dispute window.
+     Do not copy one universal TTL; name the owning lifecycle and expiry consequence.
 4. Require durable uniqueness at the operation boundary.
    - App-only `if exists return` followed by `insert` is a race. Use a unique constraint, atomic insert, upsert, conditional write, or durable ledger key.
    - Review migrations or schema definitions, not just service code, for keys such as `order_id`, `payment_id`, `refund_id`, `event_id`, `message_id`, `idempotency_key`, `campaign_id + user_id`, and `settlement_date + merchant_id`.
@@ -161,6 +174,9 @@ deduplicates the operation or rejects the stale result?"
 21. Review `PROCESSING` and lease recovery.
     - A `PROCESSING` row without lease, heartbeat, timeout, owner, or reconciliation can permanently block retries after a crash.
     - A stale processing record should recover by verifying side effects and either completing, failing safely, or allowing one fenced owner to continue.
+    - Preserve an explicit `UNKNOWN` or `RECONCILING` state when the external result cannot yet be
+      proved. Do not expire the idempotency record or mint a new effect while reconciliation or
+      manual review still owns the outcome.
 22. Review locks as helpers, not proof.
     - Distributed locks can expire, split ownership, or pause through stop-the-world events.
     - Keep durable uniqueness, conditional writes, state guards, idempotency records, or fencing tokens as the final defense.
@@ -176,6 +192,8 @@ deduplicates the operation or rejects the stale result?"
 ## Postconditions
 
 - The logical operation and attempt identities, duplicate sources, ordering aggregate, authority token, gap policy, stale-result decision, side effects, durable operation key, payload binding, response replay contract, timeout recovery, processing recovery, queue or webhook dedupe, scheduler or batch dedupe, outbox or inbox boundary, and adversarial tests are explicit.
+- Workflow, plan, step, effect, and attempt identities are separated where replanning exists, and the
+  same admitted business intent keeps one effect identity across plan versions.
 - Duplicate business requests, changed-payload key reuse, concurrent `exists` then `insert`, per-retry operation IDs, duplicate increments, timestamp ordering, sequence gaps, stale state overwrites, cancellation-as-rollback, single-flight-as-proof, provider timeout retries, pre-record external calls, duplicate webhook delivery, queue redelivery, scheduler reruns, double compensation, stuck processing rows, weak locks, and frontend-only guards are fixed or reported.
 - Duplicate safety claims are backed by configured tests, schema evidence, framework evidence, provider documentation matched to current code, or labeled as static review risk.