mustflow 2.116.3 → 2.117.0

package/templates/default/locales/en/.mustflow/skills/client-platform-strategy-review/SKILL.md

@@ -0,0 +1,236 @@
+---
+mustflow_doc: skill.client-platform-strategy-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: client-platform-strategy-review
+description: Apply this skill when a consumer or prosumer product chooses responsive web versus mobile app first, mobile web versus PWA versus cross-platform or native clients, an app as an acquisition or retention surface, native break-even users, operating-system capability dependence, or local-first versus cloud-first desktop data ownership, offline behavior, synchronization, recovery, privacy, and client-platform investment sequencing.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.client-platform-strategy-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Client Platform Strategy Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose web, PWA, cross-platform, native, local-first, cloud-first, or hybrid client architecture
+from the product job, operating-system capabilities, complete funnel economics, data authority, and
+failure recovery. Prevent platform prestige, raw install retention, or storage price from replacing
+an actual investment and usability decision.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A new B2C or prosumer service compares responsive web-first with iOS, Android, or another native
+  app-first launch.
+- A product compares mobile web, installable PWA, wrapped web, shared cross-platform client, or
+  separate native clients.
+- A proposal treats an app as acquisition, retention, notification, offline, device-capability, or
+  checkout infrastructure and needs a break-even user or retained-contribution model.
+- A desktop or mobile product compares local-only, local-first with sync, cloud-first with cache, or
+  server-only data ownership.
+- Offline work, device files, collaboration, multi-device recovery, conflict resolution, privacy,
+  encryption, account rights, or sync engineering changes the client strategy.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The client platform is already chosen and the task only compares website, Microsoft Store, Mac
+  App Store, or hybrid desktop sales and distribution; use
+  `desktop-commercial-distribution-review`.
+- The task only implements one frontend framework, native bridge, service worker, cache, installer,
+  updater, mobile permission, or platform API; use the matching implementation and platform skill.
+- The task only changes synchronization algorithms, database migrations, encryption, access
+  control, backup, or privacy behavior after the authority model is fixed; use the narrower data,
+  security, privacy, migration, or architecture skill.
+- The task only selects a framework, vendor, database, or runtime; use `technology-stack-selection`.
+- The task requests current platform-law, tax, app-store contract, or consumer-rights advice. Use
+  current official policy and qualified authority; this skill supplies the decision packet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Product job ledger: target user, first owned value, repeat cadence, session length, acquisition
+  source, sharing, search demand, price, payer, support, accessibility, and expected retention.
+- Capability ledger: camera, location, Bluetooth, wearable, background execution, notification,
+  widgets, low-latency media, offline duration, filesystem, plugins, secure hardware, and platform
+  restrictions.
+- Funnel ledger by eligible user: impression, landing or listing visit, install or open, permission,
+  signup, first value, purchase, refund, retained use, support, and contribution.
+- Client cost ledger: design, implementation, shared and platform-specific code, QA devices,
+  accessibility, analytics parity, store review, deep links, notifications, checkout restoration,
+  OS updates, support, and decommissioning.
+- Data ledger: record and file classes, authoritative owner, size and growth, device count,
+  collaboration, offline edits, consistency, deletion, retention, export, backup, restore, audit,
+  quota, abuse, and legal authority.
+- Sync and recovery ledger: local database, change log, outbox, server replica, versioning, conflict
+  policy, stale client, duplicate, clock, tombstone, account merge, key recovery, device loss, and
+  disaster recovery.
+- Current platform ledger: operating-system and browser versions, install and notification behavior,
+  payment policy, fees, permitted commerce, signing, review, capability support, region, program,
+  source date, and confidence.
+- Experiment ledger: eligible cohort, assignment before channel choice, acquisition source,
+  capability need, platform availability, self-selection, promotion, horizon, and guardrails.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate launch surface, installability, native capability, commerce, retention, and data authority.
+  One choice does not prove the others.
+- Compare web and app cohorts from the same eligible population or explicitly model self-selection.
+- Define a usable retained outcome and contribution before calculating break-even users.
+- Treat copied development multipliers, fee percentages, conversion lifts, user thresholds, storage
+  prices, and platform features as dated assumptions, not built-in defaults.
+- Refresh current platform behavior by OS, browser, region, app type, commerce type, and program
+  before changing live product or financial policy.
+- This skill does not authorize developer enrollment, app submission, payment changes, production
+  experiments, data migration, cryptographic key access, release, or deployment.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine client strategy, capability matrices, funnel and contribution models, platform
+  sequencing, data-authority maps, offline and sync contracts, recovery and privacy policies,
+  experiments, events, fixtures, tests, docs, route metadata, and synchronized templates.
+- Add explicit handoffs to frontend, mobile, desktop, payments, store distribution, accessibility,
+  sync, database, security, privacy, backup, or migration owners.
+- Replace platform ideology, raw install comparison, gross fee arithmetic, last-write-wins data loss,
+  or local-storage marketing with explicit capabilities, economics, authority, and recovery evidence.
+- Do not fork the domain model without evidence, hide platform limitations, weaken privacy or
+  accessibility, migrate user data silently, or promise offline, sync, recovery, or encryption that
+  the current architecture cannot provide.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split two primary decisions: client delivery surface and data authority. A web-first launch can
+   still use local data, and a native app can still be cloud-authoritative.
+2. Classify whether the operating system is part of the product's core value. Mark required camera,
+   continuous location, Bluetooth, wearable, background, notification, widget, low-latency media,
+   filesystem, secure hardware, or offline capability and test whether the web path actually meets
+   the requirement on each target platform.
+3. Start from the smallest surface that can deliver representative first value. Responsive web is a
+   candidate when link, search, sharing, immediate trial, and one code path dominate; native-first
+   is a candidate when a required OS capability or app-native usage loop is the product itself.
+4. Treat the web as an acquisition candidate and an installed app as a retention candidate, not as
+   universal truths. Measure how each surface changes the complete funnel for the same eligible
+   users.
+5. Separate PWA layers. Decide responsive fit, manifest and install, notification, service-worker
+   caching, offline reads, offline writes, background behavior, and sync independently. Do not build
+   a complex offline layer merely to earn a PWA label.
+6. Sequence capability investment. A reversible candidate is responsive product value, then install
+   and notification for proven repeat users, then bounded offline behavior for observed need, then
+   shared or native clients when retained contribution can pay for them.
+7. Compare client costs across the full lifecycle. Include duplicated design and implementation,
+   platform QA, devices, accessibility, analytics drift, permissions, deep links, authentication,
+   payment restoration, store review, OS changes, support, and release coordination.
+8. Use D30-or-product-cadence qualified CAC, not click cost versus install cost. Count a user only
+   after representative value and the chosen retention horizon; an app install is not an accepted
+   product outcome.
+9. Calculate net contribution per eligible user. Include payment and store costs, refund, variable
+   product cost, acquisition, support, platform operations, and retention value. If native contribution
+   per user is not higher after variable costs, more users cannot repay fixed native investment.
+10. Derive break-even users from current inputs. Divide incremental fixed and step-fixed native cost
+    by incremental retained contribution per comparable active user. Include extra acquisition cost
+    and report zero, negative, or unstable denominators instead of manufacturing a threshold.
+11. Run sensitivity around the assumptions that can reverse the result: eligible paid conversion,
+    repeat use, app retention lift, store fee, price, refund, native QA cost, new-user share, and
+    channel-specific CAC. Report a range, not one magic MAU count.
+12. Correct self-selection. App users may have higher pre-existing intent. Use staged invitations,
+    matched cohorts, randomized prompts, or another defensible design before calling observed app
+    retention causal.
+13. Map data authority by class. Keep identity, billing, entitlement, organization membership,
+    quota, abuse, audit, and legal deletion server-authoritative when central enforcement is required.
+    Decide user content authority separately.
+14. Choose local-first when immediate response, offline creation, large personal files, user custody,
+    or long-lived device ownership materially creates value. Choose cloud-first when collaboration,
+    instant cross-device state, central authorization, audit, recovery, or server-side transactions
+    dominate. Treat both as candidates, not ideology.
+15. Prefer explicit hybrids. A local-first client may use encrypted replication and backup; a
+    cloud-first client should still use a durable local cache and outbox where interrupted work must
+    survive. Name the authority and failure behavior for every data class.
+16. Price local-first engineering honestly. Include local schema migration, corruption handling,
+    change logs, retry, deduplication, tombstones, stale clients, conflict UX, compatibility,
+    encryption, key recovery, export, and support. Avoid comparing that engineering cost with raw
+    object-storage price alone.
+17. Define sync semantics before choosing an algorithm. Cover concurrent edits, delete-versus-edit,
+    uniqueness, ordering, access revocation while offline, quota crossing, account merge, and old
+    client reappearance. Last write wins and CRDTs do not decide product policy automatically.
+18. Use the simplest conflict model that meets the product. Document versions, three-way merge, or
+    conflict copies can be safer than a general collaborative CRDT when simultaneous editing is not
+    a core job.
+19. Make privacy claims reconstructable. State what remains only on device, what is replicated,
+    whether the service can decrypt it, what telemetry leaves the device, how keys are stored, and
+    how loss, export, deletion, remote wipe, and recovery work.
+20. Separate confidentiality from recoverability. End-to-end or client-side encryption can reduce
+    provider access while making forgotten-key recovery harder; define recovery keys, trusted-device
+    transfer, or explicit irrecoverability without misleading promises.
+21. Measure full outcomes: eligible acquisition, first value, qualified retained use, purchase,
+    refund, support, sync conflict, lost work, recovery success, privacy complaints, platform failure,
+    and retained contribution.
+22. Promote only a reversible strategy that meets required capabilities, improves retained
+    contribution, preserves accessible and honest UX, assigns every data authority, and has a tested
+    recovery model before irreversible migration.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Launch surface, install, native capability, commerce, retention, and data authority decisions are
+  explicit rather than collapsed into web versus app ideology.
+- Break-even uses comparable eligible users, full lifecycle costs, incremental retained contribution,
+  self-selection controls, and sensitivity ranges.
+- Every data class has an authority, offline behavior, conflict rule, privacy statement, backup, and
+  recovery owner.
+- Local-first and cloud-first claims include sync and failure cost rather than raw latency, storage
+  price, or marketing language alone.
+
+<!-- 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, browser, mobile device, payment, notification, signing,
+submission, analytics, migration, sync, encryption, backup, recovery, deployment, or production
+commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If required capabilities cannot be verified on a target surface, mark that surface unknown or
+  infeasible instead of assuming parity.
+- If comparable funnel cohorts or incremental per-user contribution are missing, report the native
+  break-even as non-decision-ready.
+- If the denominator is zero or negative, report that no finite user count repays the modeled native
+  investment under those assumptions.
+- If data authority, conflict semantics, key recovery, or lost-device recovery is undefined, do not
+  approve local-first or cloud-first migration.
+- If current store or platform policy cannot be refreshed, keep policy-dependent economics dated and
+  unverified rather than encoding them as a default.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Product job, eligible user, first value, repeat cadence, platform, and required capability
+- Responsive web, PWA, cross-platform, and native capability and lifecycle-cost matrix
+- Comparable funnel, qualified CAC, retained contribution, break-even range, sensitivity, and
+  self-selection evidence
+- Data classes, authority, local and server state, offline behavior, conflicts, sync, privacy,
+  encryption, backup, export, deletion, and recovery
+- Current platform source and date, files changed, command intents run and skipped checks
+- Remaining client-platform strategy risk

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

@@ -2,11 +2,11 @@
 mustflow_doc: skill.credit-ledger-integrity-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: credit-ledger-integrity-review
-description: Apply this skill when credits, points, wallet balances, reward points, prepaid credits, usage credits, bonus credits, loyalty points, stored-value balances, balance deductions, accruals, refunds, reversals, expirations, reservations, captures, releases, admin adjustments, ledger tables, balance caches, reconciliation jobs, settlement reports, or credit-related tests need review for ledger integrity, idempotency, atomic balance changes, concurrency, ordering, ownership, amount precision, policy snapshots, expiry lots, failure recovery, audit evidence, or reconciliation risk.
+description: Apply this skill when credits, points, wallet balances, reward points, prepaid credits, usage credits, bonus credits, loyalty points, stored-value balances, purchased versus subscription or promotional balance classes, balance deductions, accruals, refunds, reversals, expirations, rollovers, price quotes, reservations, captures, releases, admin adjustments, ledger tables, balance caches, reconciliation jobs, settlement reports, or credit-related tests need review for ledger integrity, idempotency, atomic balance changes, concurrency, ordering, ownership, amount precision, policy snapshots, expiry lots, quote binding, failure recovery, audit evidence, or reconciliation risk.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -60,7 +60,9 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 - Amount and unit ledger: integer unit or decimal representation, maximum amount, rounding rules, conversion rates, bonus rules, policy version, product price snapshot, and campaign snapshot.
 - Ownership ledger: user, tenant, wallet, account, team, family, organization, operator, source object, and current actor checks.
 - Expiry and lot ledger: FIFO, LIFO, earliest-expiry-first, bucket allocation, expiry batch, lot-level consumption, partial use, partial refund, and lot restoration behavior.
+- Balance-rights ledger: purchased top-up, subscription-included, promotional, referral, trial, enterprise commitment, refund, or admin-grant source; acquisition and policy version; expiry and rollover right; cancellation or downgrade behavior; legal or platform constraint; and spend priority.
 - Reservation ledger: reserved, captured, released, failed, expired, cancelled, partially refunded, and reversed states, plus the owner of each transition.
+- Quote and fulfillment ledger: `quote_id`, price version, input-parameter hash, exact or bounded estimate, maximum authorized amount, quote expiry, reservation identity, actual captured amount, usable-result predicate, partial-result rule, and release or refund evidence.
 - Queue and cache ledger: producer events, consumer idempotency, partitioning, outbox or inbox records, read-replica routing, cache invalidation, and balance display semantics.
 - Audit and reconciliation ledger: logs, metrics, support IDs, before/after values, daily balance-vs-ledger checks, settlement reports, and manual adjustment evidence.
 
@@ -97,9 +99,11 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 14. Model refunds as reversals. Refunds, cancellations, and corrections should reference the original ledger entry or reservation, not call a generic balance increase with no causal link.
 15. Test partial use and partial refund. Exercise cases where only part of a balance, lot, coupon, order, or mixed payment is used or refunded. Full-cancel-only assumptions are not enough.
 16. Consume expiry lots deliberately. When credits expire, inspect FIFO, LIFO, earliest-expiry-first, or policy-specific lot allocation. Record lot-level consumption so later refund and audit can reconstruct the path.
+    - Keep purchased top-up, subscription-included, promotional, trial, enterprise, and admin-grant lots distinct when their expiry, rollover, cancellation, refund, accounting, or platform rights differ. Do not collapse them into one balance and reconstruct ownership from current plan state.
 17. Race expiry and usage. Expiry batches must use the same ledger, lock, idempotency, and conditional update rules as user requests. Flag direct batch subtraction that bypasses wallet safeguards.
 18. Separate reservation from capture. Model reserved, captured, released, failed, expired, cancelled, and partially refunded states when credits are held before final purchase, fulfillment, or external payment completion.
     - This ledger owns atomic reserve, capture, and release and the balance invariant. Commands and durable workflows may consume those operations but must not redefine balance availability, ownership, or accounting transitions.
+    - Bind a reservation to an unexpired user-visible quote and immutable price snapshot. Reserve no more than the approved maximum, capture only the actual charge allowed by the quoted policy and usable-result predicate, and release the remainder on failure, cancellation, timeout recovery, or lower actual usage.
 19. Draw allowed state transitions. Prevent arbitrary `status = REFUNDED`, `status = CAPTURED`, or `status = EXPIRED` writes. Each transition should have a guard, cause, effect, and idempotency rule.
 20. Preserve queue ordering or tolerate reordering. If deduction, cancellation, refund, or expiry events use a queue, prove user, wallet, or transaction-level ordering, or make each consumer robust to reordered events.
 21. Treat message redelivery as normal. Producers, queues, schedulers, and webhooks can duplicate events. Consumer-side ledger mutation must be idempotent with durable dedupe records.
@@ -116,7 +120,7 @@ Review credit, point, and wallet balance code as an accounting ledger, not a bal
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
-- The credit surface has balance, ledger-entry, source identity, atomicity, amount/unit, ownership, expiry/lot, reservation, queue/cache, audit, and reconciliation maps.
+- The credit surface has balance, ledger-entry, source identity, atomicity, amount/unit, ownership, balance-rights, expiry/lot, quote/fulfillment, reservation, queue/cache, audit, and reconciliation maps.
 - Any mutable-balance-only path, missing source key, weak idempotency comparison, non-atomic deduction, wrong lock target, float amount, hidden rounding policy, missing DB invariant, duplicate ledger risk, generic refund, expiry race, cache-trusted deduction, stale replica read, unaudited admin adjustment, or missing reconciliation is fixed or reported with evidence.
 - Tests or explicit verification cover the highest-risk concurrency, failure, duplicate, expiry, reservation, refund, cache, and reconciliation paths available in the current scope.
 - Soft operational budgets remain outside this ledger unless they represent prepaid or money-equivalent value.
@@ -152,7 +156,7 @@ Prefer focused tests for concurrent deductions, duplicate idempotency keys, affe
 ## Output Format
 
 - Credit or wallet surface reviewed
-- Balance, ledger-entry, source identity, atomicity, amount/unit, ownership, expiry/lot, reservation, queue/cache, audit, and reconciliation ledgers
+- Balance, ledger-entry, source identity, atomicity, amount/unit, ownership, balance-rights, expiry/lot, quote/fulfillment, reservation, queue/cache, audit, and reconciliation ledgers
 - Findings or fixes for duplicate, concurrent, wrong-owner, wrong-amount, rounding, expiry, reservation, refund, cache, replica, failure-recovery, admin, and reconciliation risks
 - Nightmare-path tests or evidence added, run, skipped, or still missing
 - Command intents run

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

@@ -0,0 +1,283 @@
+---
+mustflow_doc: skill.credit-monetization-integrity-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: credit-monetization-integrity-review
+description: Apply this skill when a product changes credit-pack offers, offer timing, price-discount versus bonus-credit framing, pack count or spacing, first-purchase recommendations, purchased-credit expiry, subscription-credit rollover, promotional balances, spend order, credit price disclosure, variable-cost estimates, quote and reservation UX, breakage, repurchase, retention, or credit-monetization experiments and must optimize long-horizon contribution without deceptive equivalence, balance-rights drift, surprise deductions, or survivor-biased metrics.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.credit-monetization-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Credit Monetization Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Sell and spend product credits without optimizing a checkout click, early breakage, or raw execution
+count at the expense of customer rights, useful output, repurchase, retention, or long-horizon
+contribution. Keep offer design, balance-class policy, user-visible price authorization, technical
+ledger integrity, payment processing, accounting, and legal or platform compliance as connected but
+separately owned contracts.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A credit or usage-pack offer changes timing, trigger, eligibility, discount, bonus, limit, expiry,
+  urgency, recommendation, or first-purchase treatment.
+- A product compares price-discount and bonus-credit framing or changes how credits translate into
+  images, minutes, tasks, API calls, documents, generations, or other user-recognizable output.
+- The first-purchase screen changes between three, five, seven, custom, tiered, decoy, anchored, or
+  recommended credit packs, or changes price and unit-price spacing.
+- Purchased top-up, subscription-included, promotional, referral, trial, refund, or enterprise
+  credits change expiry, rollover, cancellation, downgrade, transfer, refund, or spend-order policy.
+- A feature changes from hidden or post-execution deduction to an exact or bounded pre-execution
+  quote, maximum authorization, reservation, success-based capture, partial settlement, or release.
+- Credit conversion, repurchase, breakage, retained use, contribution, variable cost, refund, support,
+  or experiment definitions are created, changed, reviewed, or reported.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is atomic balance mutation, lot allocation, reservation state, idempotency,
+  concurrency, expiry races, refunds, reconciliation, or admin adjustment; use
+  `credit-ledger-integrity-review` as the technical owner.
+- The main risk is checkout, provider payment, tax, invoice, receipt, refund, dispute, chargeback,
+  fraud, or payment webhook correctness; use `payment-integrity-review`.
+- The main risk is cancellation, pause, downgrade, dormant-user win-back, or save-offer profit; use
+  `subscription-retention-profit-review`.
+- The main risk is signup, pre-account activation, first-owned value, or onboarding questions without
+  a credit purchase or spend policy; use `product-onboarding-activation-review`.
+- The task only estimates internal model or compute cost and does not change a user credit right,
+  price, purchase, or deduction; use the matching cost-control skill.
+- The task requests jurisdiction-specific legal, tax, accounting, or unclaimed-property advice. Use
+  qualified authority and current primary rules; this skill supplies the product evidence packet but
+  does not decide legal classification.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Eligible-cohort ledger: eligibility, assignment unit and time, holdout, exposure, offer trigger,
+  identity joins, exclusions, prior-purchase state, product-value state, traffic, and denominator.
+- Offer ledger: offer version, trigger, surface, interruption cost, real start and expiry, pack scope,
+  discount or bonus, cap, eligibility, cooldown, price history, and suppression.
+- Value and usage ledger: first owned result, recognizable output units, free and paid usage, expected
+  cadence, depletion, active-user usage distribution, useful-result rate, and abandoned or failed use.
+- Pack ledger: price, credits, unit price, output-equivalent range, variable cost, margin, recommended
+  segment, lower and upper alternatives, custom amount, refundability, and historical selection.
+- Balance-rights ledger: acquisition class, consideration paid, policy and price version, expiry,
+  rollover, cancellation or downgrade behavior, refund, transfer, spend priority, platform rule,
+  jurisdiction review, and accounting treatment.
+- Quote and execution ledger: input parameters, exact or estimated charge, estimate range, maximum
+  authorization, quote ID and expiry, price version, reservation, actual charge, usable-result
+  predicate, partial-result rule, release, reversal, and retry identity.
+- Economics ledger: cash collected, payment and refund cost, variable service cost, support and
+  dispute cost, bonus liability, deferred or recognized revenue boundary, breakage, repurchase,
+  retention, and contribution per eligible unit over declared horizons.
+- Experiment ledger: control and variants, sequencing, power assumptions, exposure integrity,
+  cannibalization, stockpiling, delayed repurchase, guardrails, segment policy, and promotion rule.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Define the user-owned value event, balance classes, and usable-result predicate before changing an
+  offer, expiry, rollover, pack, or deduction policy.
+- Assign experiments before a behavior-dependent offer trigger. Keep assigned users who never reach
+  the trigger in the intent-to-treat denominator, while recording trigger reach and exposure
+  separately.
+- Refresh current platform, app-store, jurisdiction, contract, accounting, and tax constraints before
+  changing purchased-value expiry, cancellation forfeiture, restore, refund, or price representation.
+- Treat vendor policies, academic studies, benchmark rates, sample prices, pack ratios, and another
+  product's rollover cap as hypotheses or comparators, not repository defaults.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  price changes, promotions, balance mutations, payments, messages, experiments, or legal filings.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine offer eligibility and timing, equivalent-value calculation, pack construction and
+  recommendation, output-unit translations, balance-class policy, expiry and rollover rules,
+  user-visible quote and authorization, contribution metrics, experiment assignment, guardrails,
+  fixtures, tests, docs, route metadata, and synchronized templates.
+- Add explicit handoffs to credit-ledger, payment, accounting, tax, privacy, consumer-protection, or
+  platform review when those owners must implement or approve the policy.
+- Remove fake urgency, economically unequal framing tests presented as copy tests, dominated decoy
+  packs, hidden deductions, unsupported exact estimates, or breakage targets that reward unused value.
+- Do not retroactively rewrite purchased rights, expire balances contrary to an applicable platform
+  or legal rule, hide a required total price, or capture credits for an unusable result merely because
+  an internal provider incurred cost.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Separate six decisions: offer timing, economic framing, pack architecture, balance rights,
+   user-visible spend authorization, and ledger settlement. Do not let one winning purchase metric
+   silently choose the other five.
+2. Define the headline outcome per eligible assigned user. Prefer incremental contribution over a
+   declared short and long horizon, supported by paid conversion, useful paid output, depletion-
+   adjusted repurchase, retained use, refunds, disputes, support, and variable cost. Treat offer open,
+   checkout start, raw purchase rate, raw executions, and breakage as diagnostic events.
+3. Randomize before the offer can become eligible. Compare a no-offer or business-as-usual holdout
+   with bounded timing policies such as account completion, first owned value, a declared depletion
+   state, or a time-based reminder. Do not analyze only users who reached first success or depleted a
+   free balance.
+4. Price interruption cost. Before value, a full-screen offer can block activation; after value, an
+   offer may extend a proven job; near depletion, exposed users are fewer but intent may be stronger.
+   Preserve a nonblocking path and do not copy a universal best trigger.
+5. Anchor any real deadline to the event that creates eligibility and disclose the exact expiry.
+   Preserve the offer after refresh and across devices when promised. Do not restart countdowns,
+   invent scarcity, or begin a value-dependent offer before the user could receive value.
+6. Normalize economic value before testing copy. For price discount `d`, the paid unit-price factor
+   is `1 - d`. For bonus fraction `b`, it is `1 / (1 + b)` and the effective unit discount is
+   `b / (1 + b)`. An equivalent bonus for discount `d` is `d / (1 - d)`. Hold unit economics equal
+   when the question is framing, or label the test as an offer-value test.
+7. Translate credits into user-recognizable output. Show total credits, unit price or savings, and a
+   bounded result-equivalent derived from current product prices. Use ranges when input length,
+   duration, model, quality, or external calls vary; do not promise one exact output count from an
+   unstable mix.
+8. Measure bonus inventory correctly. Extra credits can delay the next purchase without reducing
+   satisfaction. Track consumption velocity, balance depletion, repurchase after comparable
+   depletion, cumulative cash, contribution, and retained useful output rather than declaring an
+   early repurchase decline a retention failure.
+9. Price promotional cannibalization and stockpiling. Include buyers who would have paid full price,
+   bonus credits actually consumed, future purchases displaced, refund and support cost, and heavy
+   users who pull demand forward. Cap scope from observed economics, not a universal percentage.
+10. Build pack candidates from usage and willingness evidence. Use the lower pack for safe entry, the
+    recommended pack for a declared typical segment or task horizon, and the upper pack for genuine
+    high usage. Price gaps, credit gaps, and unit discounts must be legible and economically viable.
+11. Start with the smallest pack set that represents materially different jobs. Three packs are a
+    useful first-purchase hypothesis, not a law. Compare three with five when added tiers map to real
+    segments; expose more tiers or custom amounts to repeat or high-variance buyers when evidence
+    supports them. Do not add seven merely to create an anchor.
+12. Reject fake decoys. A deliberately dominated pack can make the entire credit system look
+    manipulated. Each displayed pack needs a plausible buyer, a clear output-equivalent, and a reason
+    to exist other than making another pack look cheap.
+13. Keep recommendation honest. Name the usage basis, avoid preselecting a pack that exceeds the
+    represented need, make every alternative and unit price visible, and measure regret, refunds,
+    support, depletion, and repeat purchase by selected pack.
+14. Classify every balance lot by acquired right. Separate purchased top-up, subscription-included,
+    promotional or referral, trial, refund, enterprise commitment, and admin grant when consideration,
+    expiry, rollover, restore, cancellation, accounting, platform, or legal rights differ.
+15. Do not treat purchased-credit expiry as free margin. Cash arrives at purchase; unused rights can
+    change future service cost and revenue recognition but can also reduce conversion, trust,
+    repurchase, and retained value. Compare lawful policy variants by long-horizon contribution and
+    never use breakage alone as the objective.
+16. Gate expiry through current authority. Record platform and jurisdiction, product classification,
+    customer type, contract version, notice, restore, refund, inactivity, unclaimed-property, and
+    accounting treatment. If authority is unresolved, preserve the more durable purchased right and
+    keep promotional or subscription policy separate rather than guessing.
+17. Derive subscription rollover from cost and retention evidence. Compare full reset, bounded
+    rollover, and other lawful policies using maximum liability, usage bursts, concurrency, capacity,
+    cancellation or downgrade behavior, and long-horizon cohort contribution. A one-cycle or
+    multiple-of-quota cap is a candidate, not a universal default.
+18. Spend lots by explicit rights. Prefer the balance that would lawfully expire sooner when doing so
+    preserves user value, but keep refunds, tax, enterprise commitments, negative balances, plan
+    changes, and policy snapshots reconstructable. Never consume durable purchased value first merely
+    to manufacture subscription breakage.
+19. Preserve price-version meaning. Snapshot the feature price, pack price, bonus, output-equivalent,
+    policy, and conversion rule used at purchase and execution. Review whether later feature-price
+    changes lawfully alter old credit purchasing power; do not hide retroactive devaluation behind a
+    nominally unchanged balance.
+20. Show spend before execution. Display an exact charge when inputs fix the cost. Otherwise show a
+    defensible range and maximum authorization, the factors that can change it, remaining balance,
+    and what happens on failure or cancellation. Price visibility need not require a blocking modal
+    for every low-cost repeat action.
+21. Use a quote-reserve-settle flow. Create an expiring `quote_id` bound to actor, product, input hash,
+    price version, policy, exact or maximum amount, and idempotency identity; reserve atomically;
+    execute once; capture the allowed actual amount for a usable result; and release the remainder on
+    lower usage, failure, cancellation, or recovered timeout. Route ledger correctness through
+    `credit-ledger-integrity-review`.
+22. Define usable and partial results before charging. Distinguish full success, declared partial
+    value, user cancellation, safety refusal, provider failure, product defect, timeout with unknown
+    outcome, and duplicate retry. Internal compute cost does not by itself prove customer value or
+    authorize a deduction.
+23. Add confirmation only when consequence warrants it. Consider spend share, cash top-up, unusual
+    model or quality, irreversible output, variable maximum, or first use. Let users remember a safe
+    choice with an accessible way to inspect and change it; do not copy a universal balance percentage.
+24. Separate product, ledger, payment, and accounting evidence. A product experiment can recommend a
+    policy but cannot prove atomic balances, provider settlement, tax treatment, or revenue
+    recognition. Require the matching specialist evidence before reporting the full system ready.
+25. Predeclare guardrails and analysis. Include activation interruption, useful-output rate, latency,
+    stockpiling, depletion, unit cost, p95 cost, refunds, support, disputes, accessibility, platform
+    rejection, legal review, accounting uncertainty, and segment heterogeneity. Correct repeated
+    peeking and do not ship a post-hoc segment as established.
+26. Promote only a reversible policy whose eligible-cohort contribution improves without violating
+    purchased rights, transparent pricing, useful-result charging, ledger integrity, or platform and
+    legal constraints. Preserve old policy snapshots and a rollback path for future transactions.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Offer timing uses pre-trigger assignment, a holdout, an eligible-cohort denominator, and both
+  activation and long-horizon contribution guardrails.
+- Discount and bonus framing is compared at equal unit economics or explicitly labeled unequal.
+- Pack count and spacing follow real usage segments, legible unit economics, and non-dominated jobs
+  rather than a universal tier count or copied price ratio.
+- Purchased, subscription, promotional, trial, enterprise, refund, and admin balances retain distinct
+  policy snapshots, expiry or rollover rights, and spend order where their contracts differ.
+- Expiry and rollover decisions name current platform, jurisdiction, accounting, cost, capacity,
+  cancellation, and long-horizon retention evidence or remain unresolved.
+- Every execution shows an exact or bounded price before authorization and settles a quote through
+  reserve, usable-result capture, and release or reversal.
+- Breakage, raw execution, checkout start, and trigger-reached conversion remain diagnostics rather
+  than standalone proof of monetization success.
+
+<!-- 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 raw analytics, warehouse, payment-provider, balance-mutation, accounting, experiment,
+deployment, or production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If discount and bonus variants have different unit economics, stop calling the result a framing
+  effect and report the actual effective discount and margin difference.
+- If assignment begins after first value or depletion, report trigger-conditioned evidence and do
+  not generalize it to the eligible signup or visitor cohort.
+- If traffic cannot support timing, framing, and pack tests together, sequence them and keep the
+  remaining decisions as hypotheses rather than bundling mechanisms into one opaque variant.
+- If purchased-right expiry or cancellation forfeiture lacks current platform, jurisdiction,
+  contract, and accounting evidence, preserve the existing durable right and route the decision to
+  qualified authority.
+- If balance classes cannot be reconstructed, do not introduce a new expiry, rollover, or spend-order
+  policy until the ledger can preserve acquisition source and policy version.
+- If a variable-cost action cannot produce a defensible estimate, set a conservative authorized
+  maximum or block the paid path; do not advertise fake precision or surprise-charge afterward.
+- If execution outcome is unknown, keep the reservation pending or reconcile it under a bounded
+  policy; do not capture or release based only on a client timeout.
+- If short-horizon purchase or breakage rises while useful output, contribution, repurchase,
+  retention, refunds, disputes, support, or trust guardrails worsen, reject or narrow the treatment.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Eligible cohort, assignment, trigger, exposure, holdout, and denominator
+- Offer timing, interruption, urgency, eligibility, and suppression decision
+- Discount and bonus economic-equivalence calculation and framing result
+- Pack count, segment, output-equivalent, price spacing, recommendation, and margin decision
+- Balance classes, purchased rights, expiry, rollover, cancellation, restore, and spend-order policy
+- Exact or bounded quote, maximum authorization, reserve, usable-result capture, and release contract
+- Short- and long-horizon contribution, depletion-adjusted repurchase, cost, refund, support, dispute,
+  activation, retention, platform, legal, accounting, and trust evidence
+- Files changed
+- Command intents run and skipped checks
+- Remaining credit-monetization risk
+