repo redirection

docs/prototype-plan.md

@@ -4,7 +4,7 @@
 
 Build the smallest functional prototype that proves the core wedge for this company:
 
-`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed instantly via Pix`
+`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed quickly through the relevant local payout rail`
 
 This prototype should validate three things at once:
 
@@ -27,7 +27,7 @@ That means:
 
 ## Core hypothesis
 
-If a Brazil-based employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through `Pix`, then the company will have a strong design-partner wedge.
+If an employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through the relevant local payout rail, then the company will have a strong design-partner wedge.
 
 ## Primary prototype users
 
@@ -52,7 +52,7 @@ Needs to:
 - see what has been `earned`
 - see what is `available`
 - understand what is still pending or held in reserve
-- request a `Pix` cash-out
+- request a payout to a linked bank destination
 - trust that the numbers are correct
 
 ### Internal ops admin
@@ -134,10 +134,10 @@ Mobile-first web experience that shows:
 - current `earned`, `available`, and `settled` balances
 - transaction history
 - payout history
-- current `Pix` key on file
+- current payout destination on file
 - payout request button
 
-#### 6. `Pix` payout flow
+#### 6. Local payout flow
 
 For the prototype, use partner-led abstractions and manual controls.
 
@@ -191,19 +191,19 @@ Use one clear happy-path demo story.
 
 ### Example
 
-- employer: aesthetic clinic group in Brazil
+- employer: aesthetic clinic group
 - employee: seller named Ana
 - rule: 20 percent commission on completed payments
 - availability rule: 70 percent of commission becomes immediately `available`; 30 percent stays held until settlement
-- customer payment: `R$1,000`
+- customer payment: `1,000` in local currency
 
 System behavior:
 
-- payment received: `R$1,000`
-- commission calculated: `R$200 earned`
-- immediate availability: `R$140 available`
-- held amount: `R$60 pending settlement`
-- Ana requests `R$100` `Pix` cash-out
+- payment received: `1,000` in local currency
+- commission calculated: `200 earned`
+- immediate availability: `140 available`
+- held amount: `60 pending settlement`
+- Ana requests a `100` payout to her linked bank destination
 - employer dashboard updates liability and payout history
 
 This single scenario should work end to end before adding more complexity.
@@ -231,7 +231,7 @@ This single scenario should work end to end before adding more complexity.
 
 1. employee opens mobile web app
 2. employee sees `available` balance
-3. employee requests payout to registered `Pix` key
+3. employee requests payout to the registered bank destination
 4. payout request is validated
 5. payout is sent through mocked or manual partner adapter
 6. ledger records the payout and reduces `available`
@@ -306,7 +306,7 @@ A simple but durable architecture is enough.
 Define adapters even if they are mocked.
 
 - `PaymentProviderAdapter`
-- `PixPayoutAdapter`
+- `LocalPayoutAdapter`
 - `KycProviderAdapter`
 
 This keeps the prototype aligned with the long-term partner-led model and avoids hard-coding demo logic everywhere.
@@ -372,7 +372,7 @@ The prototype is successful if it can demonstrate all of the following in one co
 - an employer can be configured in under 30 minutes
 - a payment event generates a commission and updates balances automatically
 - an employee understands `earned` versus `available`
-- an employee can request a `Pix` payout from the `available` balance
+- an employee can request a payout from the `available` balance
 - a refund or reversal creates a visible adjustment without breaking the ledger story
 - an employer can view liability, payouts, and audit history without relying on spreadsheets
 
@@ -383,7 +383,7 @@ To move faster, these can be manual in the first prototype:
 - KYB and KYC review
 - employer contract setup
 - payment provider onboarding
-- actual `Pix` movement through a partner
+- actual payout movement through a partner
 - exception handling and customer support
 - settlement reconciliation edge cases
 
@@ -451,7 +451,7 @@ After this plan, the next useful documents would be:
 - a short product requirements doc for the prototype
 - wireframes for employer and employee flows
 - an event model spec for payments, commissions, payouts, and adjustments
-- a partner-interface spec for mocked `Pix`, KYC, and payment ingestion
+- a partner-interface spec for mocked local payouts, KYC, and payment ingestion
 
 ## Bottom line
 
@@ -459,4 +459,4 @@ The right prototype is not a broad fintech app.
 
 It is a narrow commission infrastructure demo that proves one loop extremely well:
 
-`payment event -> commission calculation -> earned and available balance -> Pix payout -> employer visibility and audit trail`
+`payment event -> commission calculation -> earned and available balance -> local payout -> employer visibility and audit trail`