The 13-Week Program

Lineage: new for LUCE, written in response to the 5-critic council review (_LUCE_COUNCIL_REVIEW.md, Finding #1: "No program spine... the single biggest flaw"). This file invents no new thresholds — every number is pulled from the module that owns it and cited inline. Current as of August 2026.

---

#HOW TO USE THIS FILE

If you're starting Monday: read the One-Page Version below, then Section 1's table, then stop — go execute Week 1, and come back to Sections 2–11 as each week arrives. You do not need to read this entire file before you start, any more than you'd read all 21 modules before opening Shopify. This file is itself organized on the same principle it's teaching: read what this week needs, not the whole reference at once.

If you're mid-program and something just went wrong: skip straight to Section 9 (Failure-Week Playbooks) or Section 7 (Quit Doctrine) — both are written to be read cold, without the rest of the file as context.

If you're deciding whether to trust this file at all: Section 1.1's module-by-module map and every checkpoint gate in Section 5 cite the exact module and section their numbers come from. Nothing in the Program Map, Budget Schedule, or Checkpoint Gates is a new threshold invented for this file — check any number against its citation if in doubt.

---

#WHY THIS FILE EXISTS

Every LUCE module ends with its own "Week-1 Action Plan." Read literally and in isolation, they contradict each other: LUCE_03's Day 1 assumes you have no product yet. LUCE_06's Day 1 assumes you have a live store with 30 days of sales data to backfill. LUCE_15's Day 5 assumes a referral program is already installed. None of them say whether they run sequentially, in parallel, or in some other order — because each module was written to stand alone, and a beginner reading the course cover-to-cover is left to guess how twenty-one standalone plans fit into one Monday morning.

They don't run in parallel. They run in the sequence below. This file is that sequence: one 13-week calendar, one budget-release schedule gated by evidence instead of dates, one consolidated weekly ritual instead of four competing ones, and an honest doctrine for when the correct move is to stop.

What this file is not: a substitute for the modules. Every technique, formula, and threshold still lives where it was taught. This file tells you when to read each section and what order to execute in — the muscles are still in the other 21 files.

---

#THE ONE-PAGE VERSION

1. The program is 13 weeks, not 90 days. Thirteen weeks at 8–12 hours/week for an operator with a day job is a more honest unit than "90 days," which implies full-time hours the target reader doesn't have.
2. Product selection (LUCE_03) runs Weeks 1–2, fully before store build. You cannot build a product page (LUCE_08) for a product you haven't scored, sampled, and passed through the hard gates.
3. Store build (LUCE_01/LUCE_08) runs Weeks 2–3, overlapping the tail of product selection — the sample is in transit while the store shell goes up.
4. The organic engine (LUCE_05) starts Week 3–4, the moment there's a live store and a sample in hand to film. Not Week 1 — you need a real product on camera, not a concept.
5. Measurement (LUCE_06) baselines the day the store goes live — not with 30 days of backfilled data. LUCE_06's own Week-1 plan says "backfill the last 30 days if the data exists"; for a brand-new store, it doesn't exist, and pretending it does with placeholder numbers corrupts every ratio downstream. Baseline from day one of real traffic.
6. Affiliate seeding (LUCE_17) runs Weeks 4–6, once organic content exists to seed creators with and a sample supply chain is proven.
7. Paid ads (LUCE_04) are gated on organic or affiliate signal — earliest possible entry is Week 6. This isn't a suggestion; LUCE_04's own Decision Tree 1 says don't spend without a signal, full stop.
8. Legal armor items split into two moments, not one module. EIN, business bank account, trademark search, and entity posture: Week 1, before any money moves (LUCE_21 §1). Sales-tax registration decisions: triggered by your first actual sale and monitored monthly thereafter, not decided by the calendar (LUCE_21 §2 — see Section 4 below).
9. Money releases on checkpoint results, never on the calendar. Five gates — Weeks 2, 4, 6, 9, 13 — each with numeric pass/pivot/kill criteria pulled straight from the modules that own those numbers.
10. The four separate "weekly reviews" in LUCE_03/06/08/15 are one 45-minute Sunday sitting, not four. This file merges them into a single agenda with a time budget per line item.
11. The Quit Doctrine is not motivational filler. Two dead products plus a bankroll under roughly the cost of one more informative test (~$150–250, per LUCE_03 §3.2's own rung pricing) means stop is the correct call — not a failure of will.
12. Tool creep is the single most avoidable way a $1,000 test budget disappears before it produces a signal. The Tool Gate Table (Section 8) defaults every paid tool to "skip" until its own module's threshold is met.
13. Five derailments cause most $1k program failures: product death Week 4, zero organic traction Week 5, a payment-processor hold at the first sales spike, demoralization Week 7, and running out of content ideas. Section 9 gives each one a literal Tuesday-night script.
14. Graduation at Week 13 is a decision tree, not a finish line: kill, iterate on product 2–3, or move toward the LUCE_02 white-label track — gated on LUCE_03 §4.4's Graduation Gate, the same four-part test every module already points to.
15. This file is the spine. The modules are the muscles. Read LUCE_M1/LUCE_M2 (the mechanism layer, when published) for why each formula works; read this file for when to run it.

---

#SECTION 1: THE PROGRAM MAP

How to read this table: "Modules read" tells you the exact sections to open that week — you do not need to read a module cover-to-cover before its week arrives. "Budget released" is gated by the prior week's checkpoint, not automatic. "Checkpoint" marks the weeks with a formal gate (full criteria in Section 5).

The three conflicts this table resolves, explicitly:

• Product selection before store build. LUCE_01's own Week-1 plan (Day 1: "Set up Shopify Basic... filter for US Warehouse tag") reads as if the store comes first. It doesn't — LUCE_03's scoring and hard gates (§1.2–1.3) have to clear before you know what store you're building. Week 1 is product hunt; Week 2–3 is store build around the winner.
• Measurement baselines live, not backfilled. LUCE_06's Week-1 plan literally says "backfill the last 30 days if the data exists." For a Week-3 store, it doesn't exist. Baseline your MER spreadsheet from the day real traffic starts (Week 3), and treat Week 1–2's zero-revenue period as exactly that — zero, not missing data to be estimated.
• Paid spend has one legitimate entry point: the Week 6 gate. LUCE_04's Decision Tree 1 already states this ("IF you have <$1,000 total remaining AND no organic/affiliate signal yet → Do not spend on paid ads"). This program map is the calendar version of that same rule.

#1.1 How each module's own Week-1 plan maps onto this calendar

Every core module ends with a "Week-1 Action Plan" written as if it were Day 1 of the whole course. It isn't — it's Day 1 of that module's own scope, and this program is what tells you which calendar week each one actually fires in. Advanced twins (11–20, minus 17) are not scheduled inside these 13 weeks at all — they belong to the post-graduation scale phase, once a SKU has cleared Section 10's gate.

---

#1.2 Worked example — one operator's 13 weeks

This continues, illustratively, the worked example LUCE_04 §8.2 and LUCE_06 §8 already built for a 30-day window — it does not introduce new canonical thresholds, only extends an existing worked number forward so the reader can see one continuous story. Treat the Week 7–13 rows as an illustration of how the gates apply to real numbers, not as a new benchmark to hit.

Product: retails $39.99, landed/fulfilled cost $12.10, contribution margin ≈65% before ads (LUCE_03 §3.2 landed-cost formula; LUCE_04 §8.2). Breakeven ROAS ≈1.54×; breakeven MER ≈1.54× (LUCE_06 §7 — the 65% row sits between the table's 60% and 70% rows, interpolating to roughly this band).

The honest lesson repeated from LUCE_06 §8 applies at 13 weeks exactly as it did at 30 days: the blended number looks better than the paid-channel-only number, and the operator's actual job is proving the paid engine can hold its own — not celebrating a blended figure that's partly carried by free organic and affiliate revenue.

---

#SECTION 2: THE BUDGET RELEASE SCHEDULE

The governing rule: money is released by checkpoint results, never by the calendar. If Week 4's organic gate doesn't clear, Week 5's affiliate-seeding dollars do not go out — you rotate the angle (LUCE_03 Decision Tree 2) and re-test with Week 3–4's tools, not new spend.

#2.1 The $1,000 split

The ladder total ($230–630) is LUCE_03's own number, not a new one — Section 3.2 of that module states it explicitly and calls the remainder "reserve for reorder-on-success or a second product attempt." This program just puts weeks next to it.

#2.2 The second-attempt reserve logic

Product death is the statistically likely outcome — LUCE_03's One-Page Version opens with "90% of dropshipping failures are product failures." The reserve exists because of that fact, not despite it.

What a restart actually costs, in plain terms: almost nothing beyond the sample and the affiliate/paid rungs, because the store shell, the Shopify/Klaviyo/GA4 setup, the email list already capturing signups, and the operator's own skill at running the scoring matrix are all sunk-but-reusable assets, not sunk-and-lost ones. A restart is not "start over" — it's "re-enter the ladder at Rung 0–1 with everything else already built." The one case where you genuinely start over is if the category, not just the product, keeps failing the Temu/Shein gate (LUCE_03 §1.3) — that's a niche problem, not a product problem, and it does mean sourcing a new prospect list, which costs time, not money.

#2.3 The full 13-week ledger

A week-by-week view of the same $1,000, so "gated by results, not the calendar" has a concrete shape. Ranges reflect the underlying rung ranges (Section 2.1) — actual spend depends on real gate outcomes, not this table.

If Weeks 4–7 don't clear their gates, the corresponding row's spend simply doesn't happen — the reserve column grows instead, and Section 2.2's restart logic takes over.

---

#SECTION 3: TIME BUDGET

Target: 8–12 hours/week. This is not a full-time-equivalent program — it's built for someone with a day job, and every module's own SOP tables were written assuming solo-operator hours, not agency hours.

#3.1 Where the hours go

#3.2 A sample week, day by day (a Weeks 4–9 pattern, once organic + affiliate + occasional paid review are all live)

This is illustrative scheduling, not a new prescription — every line item cites the section that actually owns its time estimate.

#3.3 What gets cut first when a week collapses

Day-job weeks collapse. The order below is deliberate — cut from the top, never touch the bottom without accepting the specific, named consequence.

1. Cut first: discretionary research — LUCE_03's weekly prospect-list scan (Minea/TikTok Creative Center/Amazon Movers & Shakers, ~20 min). Skipping a week here costs you nothing except a slightly staler prospect list; nothing downstream depends on this week specifically.
2. Cut second: the monthly SEO blog post (LUCE_05 §9) — it's explicitly a 12–24 month compound investment. One missed week doesn't move a 12-month curve.
3. Cut third: creative-variant expansion beyond the minimum — film 3 hooks instead of 5–8 (LUCE_05 §2.3). Fewer data points this week, not zero.
4. Protect, cut only as a last resort: the weekly batch content session. Missing it doesn't kill the product, but two consecutive misses does — see the cadence rule below.
5. Never cut: daily posting cadence. LUCE_05's own KPI table is explicit: cadence adherence below 60% for 2 weeks resets the entire 14–30 day first-sale clock. A collapsed week that still hits a bare-minimum post is recoverable; a week with zero posts is not free — it's a clock reset.
6. Never cut: the 45-minute Sunday review. It's the only point in the week where kill/scale/hold decisions get made from actual numbers instead of how the week felt. Skipping it doesn't save time — it just moves the decision-making to a worse moment (see Section 9.4, the demoralization playbook).
7. Never cut: CS response SLA. LUCE_01's KPI table sets <4h for disputes, <24h general — breaching this raises chargeback risk, and chargebacks above 1% are an outright kill signal for your merchant account (LUCE_01 §6.3, signal 5).

---

#SECTION 4: LEGAL ARMOR — WEEK 1 AND THE FIRST-SALE TRIGGER

LUCE_21 — Legal, Tax & Payments Armor — is the dedicated module for everything in this section; treat it as required reading in parallel with Week 1, not optional depth. It is explicit that it's operator education, not legal, tax, or insurance advice, and this section carries that same caveat forward.

#4.1 Week 1 — before any money moves

Business bank account, before the processor application. LUCE_21 §1.4 makes the sequencing mechanical, not just tidy: a payment processor's underwriting reads your business banking history as a risk signal, and a brand-new account with zero history reads as higher-risk than the same account six months old, independent of actual revenue. Open it Week 1, not "before the first sale" — every week of history it accrues before you apply for processing is doing work for you. (LUCE_10 §6 item 1 states the same habit from the exit-readiness angle: "never run a personal expense through business funds, even once.")

EIN — get it free, Week 1. LUCE_21 §1.3: an EIN is the IRS's business-equivalent of a Social Security Number, free and instant at irs.gov, and required to open most business bank accounts and apply for payment processing as a business rather than an individual. Anyone charging a fee for this is charging you for a government form.

Entity decision (sole proprietorship vs. LLC) — this is a real decision tree now, not a placeholder. LUCE_21 §1.2 gives the actual criteria: a sole proprietorship with a dedicated business bank account is legally sufficient and free through LUCE_03's validation ladder (Rungs 0–2) — there's no inventory liability or customer yet to protect. The calculus changes at two triggers: (1) the moment you're taking real paid ads and real sales at any volume on a physical product a stranger could be hurt by — LLC becomes "optional, lean toward yes"; (2) immediately, before first sale, for high product-liability categories (supplements, cosmetics, electronics, anything for children — LUCE_21 §6's category risk tiers). For most $1k operators in a moderate-risk category, the honest read (LUCE_21 §1.2) is: sole prop through validation, form the LLC around the same moment the Week 6 paid-gate clears and real volume starts — not on Week 1, and not left undone past first real revenue either.

Trademark clearance — run it Week 1, regardless of the entity decision. LUCE_21 §1's One-Page Version, item 10, and its Week-1 Action Plan Day 2: a five-minute USPTO TESS search on your brand name and domain, even if you've already picked the name, prevents "the two most common brand-killing events" — a post-hoc cease-and-desist forcing a rebrand after months of SEO/ad spend, or a supplier-image DMCA takedown. This costs nothing and takes minutes; there's no reason it waits past Week 1.

#4.2 The first-sale trigger — tax registration

Sales tax nexus is triggered by economic activity, not physical presence (LUCE_21 §1.2/§2, citing the 2018 Wayfair ruling) — every state sets its own revenue/transaction threshold, commonly shaped like ~$100,000 or 200 transactions per state, though LUCE_21 is explicit that this shape is increasingly the exception as states simplify to dollar-only tests, and every number is state-specific [Verify per state]. At the $1k-operator's realistic first-90-day revenue, LUCE_21 §2.7 is direct: "most solo operators are genuinely unlikely to have crossed an individual state's economic nexus threshold yet" — this is not a reason to ignore the topic, only a reason not to panic-register in 45 states on Week 1.

What actually changes the risk profile immediately, not gradually (LUCE_21 §2.7): (1) any physical presence in a state — including inventory sitting in a 3PL/US-warehouse fulfillment center, which is the default model this whole program runs on (LUCE_01 §2.1) — creates nexus with no threshold at all; (2) a single state's sales concentrating past its own threshold, which can happen fast off one viral, geographically concentrated moment; (3) a multi-location 3PL relationship.

The concrete Week 3 action, from LUCE_21 §2.4: enable Shopify Tax at store launch. It calculates rates and tracks how close you are to each state's threshold — a genuine early-warning dashboard — but LUCE_21 is explicit about what it does not do: it doesn't register you with any state, file returns, or remit payment. That chain (register → collect → file → remit) stays the operator's job once a threshold is crossed. Check the dashboard monthly (LUCE_21 SOPs) starting Week 3, and register in a state the moment you cross its threshold or gain any physical/inventory presence there — not before, and not late.

The tax set-aside, from first sale onward. LUCE_09's P&L template and LUCE_21 §9/§12 both carry a 25–28% pass-through tax provision line — as a pass-through entity, business profit is taxed on your personal return whether or not you've moved the cash to yourself, which is why quarterly estimated payments exist (the US system is pay-as-you-go, not pay-once-a-year). Open a separate tax set-aside account the week of your first sale and route 25–28% of every profitable week into it — LUCE_21's own Week-1 plan, Day 7, treats this as a non-negotiable habit, not a month-13 cleanup task.

---

#SECTION 5: CHECKPOINT GATES

Every number below is cited to the module and section that owns it. Nothing here is a new threshold.

Why gates, not a calendar. A 13-week program written purely as a calendar ("Week 6: start paid ads") would repeat the exact mistake the council flagged in the original 21 Week-1 plans — it would tell you what to do on a date regardless of whether the evidence supports doing it. Every gate below converts a module's own kill/advance threshold into a go/no-go moment this program actually enforces, so "Week 6" means "the earliest a paid-gate decision is possible," not "the week paid spend is due."

#Gate 1 — Week 2 (Rung 1: sample order)

Pass: proceed to store build (Week 3). Kill: requalify a second supplier before any further spend, or return to the Week 1 prospect list (LUCE_03 Decision Tree 2).

#Gate 2 — Week 4 (Rung 2: organic content test)

Pass: advance to affiliate seeding (Weeks 4–6). Advance-with-caution: strong engagement, no purchase-intent comments → rotate to an untested angle before killing (LUCE_03 Decision Tree 2). Kill: zero videos clear 2% engagement after 14 days of consistent posting — this reads as a product signal, not a creative one.

#Gate 3 — Week 6 (paid-spend gate)

Pass: launch the $20–30/day, 5-day Spark Ad test on the proven organic hook (LUCE_04 §7.1). Fail: do not spend on paid ads — return to Rung 2/3 with a rotated angle.

(Full decision tree for this gate is diagrammed in Section 6 below.)

#Gate 4 — Week 9 (mid-program viability)

Pass: continue scaling product 1, or begin Rung 0–1 on product 2 with reserve. Kill: invoke the Quit Doctrine (Section 7) if the bankroll test also fails.

Also check at Gate 4: LUCE_21's monthly SOP — state-by-state revenue against sales-tax nexus thresholds on the Shopify Tax dashboard, and chargeback ratio against the processor's risk gate (LUCE_21 §3, Section 9.3 above). Nine weeks in is roughly when a genuinely growing $1k operator starts to have enough volume for either to matter for the first time — check both now, not only when a state notice or a processor hold forces the issue.

#Gate 5 — Week 13 (graduation)

Also check at Gate 5, before any scale decision: if the outcome is "scale toward LUCE_02/LUCE_12," the entity-and-insurance posture from Section 4.1 needs to be settled now, not deferred — a bulk PO means real inventory liability exists (LUCE_21 §1.2), and LUCE_21 §6 is explicit that high product-liability categories need coverage bound before the first unit of the new order ships, not after.

Full outcomes tree in Section 10.

---

#SECTION 6: THE CONSOLIDATED WEEKLY RITUAL

The council found four separate "weekly review" prescriptions living in LUCE_03, LUCE_06, LUCE_08, and LUCE_15 — each written as if it were the only one a reader would run. Run once, on Sunday, 45 minutes total. Each line cites which module's review it replaced.

#6.1 The 45-minute Sunday operating review

Total: 45 minutes. New candidate research (LUCE_03's Minea/Ad Library/Amazon scan) is deliberately not in this list during Weeks 1–7 — it belongs to Week 1's one-time sprint and Week 12's second-product optionality window, not a weekly habit while a single product is being validated. Add it back in at Week 12 if reserve supports a second ladder attempt.

#6.2 The daily 10-minute check

---

#SECTION 7: THE QUIT DOCTRINE

No LUCE module currently tells a twice-failed operator when stopping is the correct decision — the council flagged this by name ("no 'when to quit' doctrine... kill switches exist per product, but no module tells the twice-failed, $1k-gone operator when stopping is the correct decision"). This section is that doctrine.

#7.1 The rule

Two products dead, and remaining bankroll below the cost of one more informative test (~$150–250), means stop is the correct decision — not a failure of will.

The $150–250 figure isn't invented for this section — it's derived from LUCE_03 §3.2's own rung pricing: a sample order ($30–80) plus an organic content test ($0–50) plus the low end of affiliate seeding ($50–150) is the minimum spend that has ever, in this course's own framework, produced a real signal about a product. Below that combined floor, you cannot actually run Rungs 1–3 again — you'd be testing with less capital than the ladder itself requires, which means any result you get is noise, not signal.

#7.2 What stopping correctly looks like

Stopping is not "delete the store and start over in six months." It's a deliberate handoff of what you built to whatever comes next — another attempt, later, with more capital, or a different venture entirely.

What you keep:

• The store shell. Shopify account, theme, product-page structure, Klaviyo flows, GA4/Clarity instrumentation — all reusable at $0 marginal cost for a future attempt (Section 2.2).
• The skills. You now know how to run the LUCE_03 scoring matrix, order and evaluate a sample, film a hook-tested organic batch, seed affiliates, and read a breakeven-ROAS decision — skills that transfer to any future product, in this niche or another.
• The list. Whatever email/SMS subscribers, TikTok following, and saved creative assets you accumulated do not evaporate when a product dies. They are the actual asset of the attempt, more durable than the product itself (LUCE_05 §1: "the list is the asset — the only customer relationship no algorithm can revoke").

#7.3 Quit signals vs. variance

Confusing a bad week with a dead product is the single most common way operators either quit too early or bleed out too late. The modules already distinguish these — this section just names the distinction explicitly:

The pattern across every one of these: variance is a short window with no confirmed structural cause; a quit signal is a threshold breach that persists for the module's own defined evaluation window, with alternative explanations (tracking, seasonality, TikTok's post-JV volatility per LUCE_06 §1.3) already ruled out.

#7.4 The anti-sunk-cost rule

Money already spent — the sample cost, the affiliate seeding budget, last week's ad spend — has no bearing on the next dollar's decision. The only question that matters going forward is whether the next $150–250 is likely to produce information you don't already have. LUCE_01 §6.3 says it plainly: "don't give it more time... time spent on a dead product is time not spent finding a live one." A kill decision at Week 9 is not an admission that Weeks 1–8 were wasted — the skills and store shell from Section 7.2 mean they weren't — it's a refusal to let money already gone buy a worse decision about money not yet spent.

---

#SECTION 8: TOOL GATE TABLE

Default for the $1k tier: free stack until the cited gate passes. The council found tool-subscription creep — Minea + AutoDS + Zendrop Pro + Loox stacking to 15–20% of a $1k operator's total capital before a single sale — eats exactly the margin this program is trying to protect. Every row below defaults to "skip."

The concrete math the council was pointing at: Minea Premium ($99/mo) + AutoDS ($29.90/mo) + Zendrop Pro ($49/mo) + Loox ($15/mo) = $192.90 in month one alone — roughly 19% of the entire $1,000 bankroll, spent before Gate 1 even resolves, on tools whose free substitutes (TikTok Creative Center, the Facebook Ad Library, CJ/Zendrop's free tier, a $9 reviews app) do the same job at this order volume. That gap is not a rounding error — it's most of a Rung 4 paid test, gone before the product is even validated. This is why every row below defaults to "skip" until its own threshold is met, not "buy now, cancel later."

---

#SECTION 9: FAILURE-WEEK PLAYBOOKS

Five derailments account for most $1k-program failures. Each gets a literal "what to do this Tuesday night" script — not a pep talk, a checklist.

#9.1 Product dies Week 4

What happened: Gate 2 (organic, §3.2 Rung 2) genuinely failed — 14 days of consistent posting, nothing clears 2% engagement, no purchase-intent comments.

Tuesday night script:

1. Pull the actual KPI numbers before deciding anything — confirm this is a real kill threshold breach, not a logging gap (check the content calendar against posted dates).
2. Run the 10-minute post-mortem: per LUCE_03 §3.2, this reads as a product signal, not a creative one — don't reshoot the same product with new hooks.
3. Open the original Week 1 prospect list (LUCE_03 Week-1 Day 1 — you built 10 candidates, not one).
4. Score the next-highest candidate against the weighted matrix (LUCE_03 §1.2) tonight.
5. Order its sample Wednesday morning. Reserve math from Section 2.2 confirms this costs $0 marginal beyond the new sample.
6. Why this works: the store shell, the skills, and the list all survive the product's death (Section 7.2) — only the SKU dies, and the ladder is cheap enough at Rung 1–2 that a restart barely touches the reserve (Section 2.2's table).

#9.2 Zero organic traction Week 5

What happened: posting has been happening, but under 2% engagement and no purchase-intent signal — and this is a week past Gate 2, so the underlying question is whether the angle, not the product, is the problem.

Tuesday night script:

1. Check cadence adherence first — LUCE_05's KPI table: under 60% adherence for 2 weeks resets the entire clock. If cadence was actually the problem, fix cadence before touching the product or the angle.
2. If cadence held (≥90%) and traction is still zero, this is the "advance-with-caution" branch of LUCE_03 Decision Tree 2 — rotate to an untested angle, don't kill yet.
3. Pull 3-second view-rate data per hook (LUCE_05 §2.3). Retire anything under 15%.
4. Film 3 new videos tonight or tomorrow using an angle from the Hero Angle Method (LUCE_03 §2.2) you haven't tested yet — mine 1-star/5-star competitor reviews for the language if you're out of angles.
5. Why this works: LUCE_03's own framework treats a cadence failure and an angle failure as different diagnoses with different fixes — collapsing them into one panicked "the product is dead" conclusion is how a fixable Week 5 becomes a wrongly-killed Week 5.

#9.3 Processor hold at the first sales spike

What happened: a sudden order spike triggers a payment-processor rolling reserve or a volume-spike freeze. This is not a beginner mistake — LUCE_21 §3.3 is explicit that "new account + viral spike" is the single most common freeze scenario, precisely because a beginner's sudden 10× day looks statistically identical, to an automated risk system, to account-takeover fraud or a bust-out scheme. You did nothing wrong; you look like the pattern the system is built to catch.

The mechanism (LUCE_21 §3.1–3.2): a payment processor is carrying your chargeback liability on its own balance sheet for roughly 120 days after every transaction — it is functionally a short-term lender, not a neutral pipe, and it prices you like a credit risk. A rolling reserve — commonly 10–25% of processed volume, held 90–180 days — is the processor keeping enough of your own money on hand to cover disputes if they occur. LUCE_21 §3.5's worked example: a $95,000 viral month can leave $33,000 of your own already-earned revenue sitting outside your control by the end of the following month, at a 20% reserve rate. That's real cash you can't use to reorder inventory or cover ad spend — precisely when reordering matters most.

Tuesday night script:

1. Do not panic-refund orders. Keep fulfilling on schedule — cancelling orders reads worse to a processor's risk model than a hold does.
2. Protect the two levers already tracked daily: chargeback rate under 0.5% (LUCE_06 KPI table) and CS response time under 4 hours for disputes (LUCE_01 KPI table). Both feed the same risk model that decided to freeze you.
3. Gather order and tracking documentation tonight so you can respond to the processor's request same-day (LUCE_21 §3.6 item 1's "heads-up before the spike is materially better than a freeze during it" — if you saw this coming, this step should have happened before the spike, not after).
4. Contact processor support first thing Wednesday morning with that documentation ready.
5. If you don't already have a second, already-approved backup processor (LUCE_21 §3.6 item 3), start that application this week regardless of how this hold resolves — running 100% of volume through a single processor with no fallback turns any future freeze into total business paralysis, not a cash-flow event.
6. Why this works: a processor hold is a risk-scoring event, not a verdict — LUCE_21's own survival plan (§3.6) is built around graduated volume, a recognizable billing descriptor, a backup processor, and a cash buffer sized to a 25% hold. The fastest way out of one hold is proving the account is clean; the way to never be structurally exposed to the next one is having the backup processor and buffer in place before it happens.

#9.4 Demoralization Week 7

What happened: nothing measurable — this is a morale collapse, usually right after the Week 6 paid-gate decision, win or lose.

Tuesday night script:

1. Do not make any kill or spend decision tonight, on a low-energy night, off feelings.
2. Re-read what you wrote in Week 1 — the prospect list, the scoring rationale, the reason you picked this candidate.
3. Run the 45-minute Sunday review early, tonight, using only the actual numbers (Section 6.1) — not a summary from memory.
4. Compare those numbers against Section 7.3's variance-vs-quit-signal table. If you're in the "variance" column, the correct action is explicitly no action — hold one more week before feelings get a vote in a decision that belongs to the data.
5. Why this works: Week 7 sits right after the first paid-test evaluation (Gate 3's aftermath), which is exactly when a hold-band result (Section 1.2's worked example: 1.28× against a 1.54× breakeven) feels like failure but reads, per LUCE_04 Tree 2, as an ordinary refresh-and-retry signal — the demoralization is about the feeling, not the number.

#9.5 Ran out of content ideas

What happened: the five-pillar mix (LUCE_05 §2.2) has been run dry, and nothing new is coming to mind.

Tuesday night script:

1. Pull 20 fresh reviews from a competitor product — 10 one-star, 10 five-star (LUCE_03 §2.2, the Hero Angle Method). The 1-stars reveal objections; the 5-stars reveal outcomes people actually bought.
2. Run the AI-assisted hook-matrix workflow (LUCE_04 §6.4) tonight: feed it your product brief, top 3 angles, and 2 competitor reference ads. Output: 9 hook lines across 3 angles, plus a shot list — draft only, edited by you before anything ships.
3. Cross-check against LUCE_17 Part 6's AI-assisted brief workflow if you're also briefing an affiliate creator this week — same mining exercise, different output format.
4. You now have a week of content without having invented anything from scratch — you mined it from people who already bought the product category.

---

#SECTION 10: GRADUATION — THE WEEK 13 OUTCOMES TREE

AT WEEK 13, run every live SKU through the Graduation Gate (LUCE_03 §4.4):

IF contribution margin ≥15% for 4 consecutive weeks
   AND sustained velocity (MOQ sells through in 60–90 days)
   AND ownable differentiation (can alter at the factory level)
   AND trend durability passes the 12–36 month filter
  → SCALE toward the LUCE_02/LUCE_12 white-label track.
     Move to bulk-import economics; expect landed cost to drop
     10–20% at MOQ pricing (LUCE_03 §4.4) — this is where the
     "generic 3–7%" margin band starts becoming the "branded
     15–35%" band (LUCE_01 §1.1).

IF the product cleared the validation ladder (Gates 1–3) but
   does NOT clear all four Graduation Gate criteria
  → ITERATE. Keep it as a dropship SKU inside a portfolio
     (LUCE_03 §4.1) — hero, upsell, or backend, not necessarily
     a bulk PO candidate. Begin Rung 0 on product 2 or 3 with
     remaining reserve (Section 2.2), using the Week 1 prospect
     list's next-highest scorers.

IF cumulative kill signals hit (LUCE_01 §6.3, three or more
   together) AND remaining bankroll is under the Section 7
   Quit Doctrine floor (~$150–250)
  → KILL. This is the correct decision, not a failure — see
     Section 7.2 for what you keep and carry forward.

IF none of the above cleanly applies (e.g., a product is
   marginal — 2 of 4 graduation criteria pass)
  → Default to ITERATE, not SCALE. LUCE_03 §4.4 is explicit
     that a bulk PO is a different capital commitment, not a
     supplier swap — never graduate on optimism.

---

#DECISION TREE — THE WEEK 6 PAID-SPEND GATE

START: It's Week 6. You have organic content history and,
       possibly, affiliate seeding results.

IF you have <$1,000 total remaining AND no organic/affiliate
   signal yet
  → Do NOT spend on paid ads. Return to Rung 2/3 (LUCE_03 §3.2)
     with a rotated angle. Re-evaluate at Week 8, not Week 6+1.

IF you have an organic OR affiliate signal
   (engagement ≥2%, OR ≥1 affiliate-driven order)
  → Run a $20–30/day TikTok Spark Ad test on the proven hook,
     5 days (LUCE_04 §7.1; LUCE_03 §3.2 Rung 4).
     IF CTR >1.5% and CPC <$1.50
       → Advance to a full testing-phase campaign (LUCE_04 §3.3);
          consider adding Meta (LUCE_04 §2.1).
     ELSE
       → Rotate to the next angle before spending further.

AT day 7 of that test:
  IF ROAS > 1.5× (LUCE_03 §3.2 Rung 4 decision gate)
    → SCALE. Add creative and audiences (LUCE_04 §8.3).
  IF ROAS is 1–1.5×
    → HOLD. One more creative batch, one more angle, re-judge.
  IF ROAS < 1×
    → KILL. The market is telling you the product, price, or
       angle is wrong — not that more spend would find out.

---

#FAILURE MODES — RUNNING THE PROGRAM ITSELF

Section 9 covers the five most likely product/market derailments. These are the five most likely program-execution mistakes — the ways an operator sabotages a perfectly good product by running this file wrong.

---

#SECTION 11: THE PRINTABLE 13-WEEK CHECKLIST

A condensed, checkbox version of Section 1's table — print it, tape it up, check boxes as weeks close. Every line traces back to a fuller citation earlier in this file.

Week 1 — Product hunt + legal foundation

• 10-candidate prospect list built (LUCE_03 Week-1 Day 1)
• Hard gates + Temu/Shein gate run on all candidates
• Weighted matrix scored; top candidate selected
• EIN obtained free at irs.gov; business bank account + card opened (LUCE_21 §1.3–1.4)
• USPTO TESS trademark search run on brand name + domain (LUCE_21 Week-1 Day 2)
• Entity posture decided against the LUCE_21 §1.2 decision tree (Section 4.1)

Week 2 — Sample + store shell begins

• Sample ordered from top scorer
• Shopify Basic set up; US-warehouse supplier app connected
• Gate 1 check: sample quality ≥7/10, landed cost within 15% of estimate

Week 3 — Store build completes; baseline starts; organic begins

• 18-element product page live, incl. shipping-speed promise
• GA4 + Microsoft Clarity installed
• Shopify Tax enabled for automatic nexus tracking (LUCE_21 §2.4)
• MER spreadsheet built; Day 1 baseline logged (no backfill)
• First organic batch (5 videos) filmed and posted

Week 4 — Organic running; TikTok Shop live; first-sale legal trigger

• Daily/near-daily posting cadence holding ≥90%
• TikTok Shop seller account live, Performance Score ≥3.5
• Separate tax set-aside account opened at first sale; 25–28% of profit routed in (LUCE_21 §9, LUCE_09 P&L template)
• Gate 2 check: ≥2% engagement + purchase-intent signal on ≥1 video

Week 5 — Affiliate seeding ramps

• Outreach sent to 30+ micro/nano creators
• 10–20 creators seeded with free product + 15–20% commission

Week 6 — Paid-gate decision

• Organic/affiliate signal evaluated against Gate 3 criteria
• Gate 3 check: if cleared, $20–30/day Spark Ad test launched (5 days)

Week 7 — Paid test evaluation

• Day-7 ROAS read against breakeven (LUCE_04 Tree 2)
• Hold, scale 20%, or kill decision made and logged

Week 8 — Consolidate the winner

• $0 CRO audit run; top defect fixed
• 2-consecutive-week aMER check before further scaling

Week 9 — Mid-program viability check

• Full P&L reviewed against landed-cost model
• Gate 4 check: continue / pivot to product 2 / Quit Doctrine review

Week 10 — Systemize creative

• Hook matrix batch-produced for the week
• Top-quartile affiliates evaluated for graduation to flat-fee UGC

Week 11 — Retention layer

• Welcome + abandoned-checkout flow conversion audited
• SMS compliance windows confirmed

Week 12 — Second-product optionality

• Reserve status checked against Section 2.3's ledger
• Rung 0–1 opened on candidate #2, if reserve supports it

Week 13 — Graduation

• Every live SKU run through the four-part Graduation Gate
• Gate 5 check: kill / iterate / scale outcome logged and acted on

---

#SECTION 12: QUICK GLOSSARY

For the acronyms used above without a first-use definition — a full course-wide glossary is on the LUCE roadmap for LUCE_00; this is the local subset this file needs.

---

#SELF-TEST

1. Per Section 1, why does product selection (LUCE_03) have to run before store build (LUCE_01/LUCE_08), rather than in parallel, in this program's sequencing?
2. A reader is on Week 3 with a brand-new store and no sales history yet. Per Section 1's resolution of the measurement-baseline conflict, what should they do with LUCE_06's "backfill the last 30 days" instruction?
3. At Week 9, an operator has $180 left after two dead products. Per Section 7.1, is this a Quit Doctrine trigger — and why does the $150–250 figure come from LUCE_03 §3.2 rather than being invented for this file?
4. Name two of the four items in the Section 6.1 weekly ritual and which of the four original module-level "weekly reviews" (LUCE_03/06/08/15) each one replaces.
5. Per the Week 6 decision tree, what specifically has to be true before ANY paid ad spend is justified — and which module's Decision Tree 1 does this rule come from originally?
6. Per Section 1.2's worked example, at Week 7 the operator's first paid test comes back at ROAS 1.28× against a 1.54× breakeven. Per LUCE_04 Tree 2, is this an automatic kill? Why or why not?
7. Per Section 3.3, name the one item that's protected even when a week collapses because breaching its SLA is itself a kill-signal input elsewhere in the course.

<details> <summary>Answers</summary>

1. Because you cannot build an 18-element product page (LUCE_08) or a landed-cost model (LUCE_01 §3.1) for a product that hasn't been scored, sampled, and passed through LUCE_03's hard gates and Temu/Shein gate first — the store is built around the winning candidate, not in parallel with the search for one.
2. Don't backfill with placeholder or estimated data. LUCE_06's instruction assumes the reader already has 30 days of real numbers; a Week-3 store doesn't. Baseline the MER spreadsheet from the day real traffic starts (Week 3) and treat the pre-launch period as zero, not as missing data to reconstruct.
3. Yes — $180 is below the $150–250 floor. The figure isn't invented for this file; it's derived directly from LUCE_03 §3.2's own rung pricing (sample $30–80 + organic $0–50 + low-end affiliate seeding $50–150), which is the minimum combined spend the course's own framework has ever shown produces a real product signal. Below that floor, any "test" you could still afford wouldn't actually be able to run the ladder that produces signal.
4. Any two of: (1) MER/aMER vs. target pull — replaces LUCE_06 §3.1/§3.3 and LUCE_15 §8.1 item 1; (2) product/ladder status review — replaces LUCE_03's weekly SOP item 5; (3) store health/CVR spot-check — replaces LUCE_08's weekly SOP items 1–2; (4) hook-test and creative-fatigue review — replaces LUCE_05 §2.3 and LUCE_15 §8.1 items 4–5.
5. An organic engagement signal (≥2% on at least one video) OR an affiliate-driven order has to exist first. This rule originates in LUCE_04's own Decision Tree 1 ("IF you have <$1,000 total remaining AND no organic/affiliate signal yet → Do not spend on paid ads") — this program's Week 6 gate is the calendar placement of that same rule, not a new one.
6. No. Per LUCE_04 Tree 2, ROAS between breakeven and target is a "hold" signal — refresh one variable (hook, CTA, or audience) and re-test, not an automatic kill. Only ROAS below breakeven, sustained past the test window with no tracking explanation, triggers a kill.
7. CS response SLA (<4h disputes, <24h general, LUCE_01 KPI table). Breaching it raises chargeback risk, and a chargeback rate above 1% is itself one of LUCE_01 §6.3's six kill signals — so a collapsed week that skips CS can manufacture a false kill signal on an otherwise-healthy product.

</details>

---

#CROSS-REFERENCES

• → LUCE_00 (Course Index): the "How to Use This Course" beginner path (03 → 01 → 08 → 05 → 06 → 04) is the module-order skeleton this file turns into an actual calendar.
• → LUCE_03 (Product Selection): owns the validation ladder, the scoring matrix, all four rung kill thresholds, and the Graduation Gate — the single most-cited module in this file.
• → LUCE_01 (Dropshipping): owns the six kill signals, the $0→$30k roadmap this program's Weeks 8–13 compress into a single 13-week pass, and the store-build SOPs.
• → LUCE_04 (Advertising): owns the paid-spend gate (Decision Tree 1), the lean-tier budget ladder (§7.1), and the breakeven-ROAS math behind Gate 3 and the Week 6 decision tree.
• → LUCE_05 (Marketing): owns the organic engine, the hook bank, and the posting-cadence kill switch that Section 3.2's "never cut" rule depends on.
• → LUCE_06 (MER & Measurement): owns the canonical kill/scale table (§7) that every later checkpoint gate in this file points back to, and the baseline-not-backfill principle in Section 1.
• → LUCE_08 (Store CRO): owns the 18-element product page and the $0 CRO audit referenced in Week 8 and the Sunday ritual.
• → LUCE_17 (Influencer/UGC System): owns the affiliate seeding ladder and graduation criteria referenced in Weeks 4–6 and Week 10.
• → LUCE_10 (Exit Strategy) §6: the exit-readiness framing of the same Week 1 bank-account habit LUCE_21 owns mechanically.
• → LUCE_21 (Legal, Tax & Payments Armor): owns the entity decision tree, EIN/bank-account sequencing, trademark clearance, sales-tax nexus mechanics, and the payment-processor rolling-reserve survival plan behind Section 4 and Section 9.3 of this file — read it in full during Week 1, not skimmed.
• → LUCE_02 / LUCE_12 (Whitelabeling): the destination of the Week 13 "scale" branch, gated on the same Graduation Gate LUCE_03 already defines.
• → LUCE_M1 / LUCE_M2 (mechanism layer, when published): for why the formulas in this file's cited sections work — this file tells you when to run them, the mechanism layer explains the underlying math and behavioral logic.

---

This file is the spine. The twenty-one modules it sequences are the muscles — read them for the mechanism, read this one for the calendar.

LUCE — Launch. Unit Economics. Compound. Exit.