@synap-core/cli 1.7.0 → 1.10.0

package/templates/skills/stellar-scf-grants-advisor/reference/01-methodology.md

@@ -0,0 +1,96 @@
+# Methodology: how The Arch Consulting reviews an SCF dossier
+
+This is the master process every review follows. Read this before your first review of any session.
+
+## Why a structured methodology
+
+Stellar Community Fund panels review 50 to 80 submissions per round. They reject 70 to 75 percent of them. The 25 to 30 percent who win share a remarkably stable set of attributes. The 70 to 75 percent who lose share an equally stable set of failure modes. Random advice does not move a dossier from one bucket to the other. Pattern-anchored advice does.
+
+The methodology converts that asymmetry into a repeatable seven-step process.
+
+## The seven steps
+
+### Step 1: read what the client actually submitted
+
+Open the Project Abstract sheet (for Abstract phase) or the Application Build sheet (for Build phase). Read every cell. Note the fields the client left empty. Note any inconsistency between fields (for example: budget mentioned in Q4 abstract that doesn't match the budget mentioned in Q11 Build intro). The panel reads horizontally across fields too; inconsistencies they spot cost the client credibility.
+
+### Step 2: read every public source about the project
+
+Before scoring, gather context:
+- The project website (web-fetch the URL provided in Q5).
+- Any deck, technical architecture link, or video URL.
+- LinkedIn profiles of the founders (look up the URLs in Q10).
+- The X / Twitter and Discord handles if provided.
+- Any GitHub repository if mentioned in Q5 of Build phase.
+
+What you discover here often contradicts or amplifies what the client wrote. A founder claiming to be "ex-BNP Paribas" might turn out to be a one-year client advisor at a regional branch, or might turn out to have led a regulated business line, both matter for how you score the team section. A website tagline like "Bankruptcy-proof gold ownership with Swiss-grade security" might reveal a positioning the client forgot to put in the Abstract.
+
+**Always check for assertion vs reality.** When the client overclaims (rare but it happens), point it out diplomatically: the panel will check too.
+
+### Step 3: score against the 14 signals
+
+Use `reference/02-scoring-framework.md`. For each of the 14 signals, give the dossier a score from 1 to 10. A score below 5 is a flag for rewrite. A score below 3 is a flag for blocker. Track the lowest signal: that is the limiting factor for the dossier's overall probability of acceptance.
+
+### Step 4: identify which recurring rejection patterns are triggered
+
+Use `reference/03-rejection-patterns.md`. There are 12 documented patterns that have caused most rejections in past rounds. For each pattern that the current dossier shows, you need to:
+- Name the pattern in plain language.
+- Explain why the panel cares (the mechanism, not the label).
+- Cite two or three past rejected dossiers that died on this exact pattern.
+- Propose the specific fix.
+
+This step is where you do the most communication work for the client. Most of them do not know these patterns exist. Help them see them.
+
+### Step 5: surface the winning patterns the dossier already has
+
+Use `reference/04-winner-patterns.md`. The same care for past rejects applies in reverse: when a dossier has elements that mirror past winners, name them so the client builds confidence and so we preserve those elements in any rewrite. A dossier that already nailed the "doxxed team with verifiable past shipped product" pattern should keep that strength front and center.
+
+### Step 6: compare directly against named past submissions
+
+Use `reference/10-corpus-winners.md` and `reference/11-corpus-rejects.md`. Pick 10 to 15 past submissions in the same category (regulated finance, gaming, RWA, B2B marketplace, etc.) and lay them out side-by-side with the current dossier. For each past submission, write a single line that captures the comparison and the lesson.
+
+This is the most evidence-rich part of any review. It also lets you anchor budget recommendations on real awards.
+
+### Step 7: write the deliverable
+
+Generate the Excel review using `reference/13-excel-output-spec.md`. Then present a concise chat summary with the probability estimate before and after fixes, the top three to five actions, and the link.
+
+## What separates a good review from a bad one
+
+A bad review repeats SCF guidance and adds generic recommendations. A good review does four things every time:
+
+1. **Anchors every claim on a named past dossier.** "We've seen this fail" is opinion. "This is exactly why Stablpay was rejected at $129K in SCF #40" is evidence.
+
+2. **Pairs every problem with a paste-ready rewrite.** The client should never wonder how to apply the feedback. The rewrite column gives them text they can copy directly into the orange cell.
+
+3. **Uses client-friendly language throughout.** Internal terms like "kill signature" or "corpus" stay internal. To the client we say "common rejection pattern we've seen in past SCF rounds" or "our database of 130+ rejected and 79+ awarded dossiers."
+
+4. **Ends with a budget recommendation anchored on a named winner.** Never recommend a budget without naming a past winner with a comparable profile.
+
+## Common workflow variations
+
+### Variation A: client sent only contact info, no Abstract
+
+Tell the client what's missing and what you need. Do not pretend you can review without seeing the field contents. The Q10 Contact Infos sheet alone does not let you score anything.
+
+### Variation B: client wants you to write the Abstract from scratch
+
+Use `reference/08-abstract-fields.md`. Field by field, draft what they should submit. Flag the information you need from them (founder LinkedIn URLs, vault partner name, regulatory framework, etc.) in placeholder brackets.
+
+### Variation C: client passed the Abstract phase and is moving to Build
+
+The Build phase is more technically rigorous. Use `reference/09-build-fields.md`. The biggest risks in Build phase are: empty Q5 Code URL, empty Q6 Video URL, empty Q10 Technical Architecture link, generic deliverable descriptions, and inconsistency between the approved Abstract and the new Build content.
+
+### Variation D: client lost a previous round and is reapplying
+
+Read `reference/05-comeback-patterns.md` first. There are 13 documented cases of rejected-then-won dossiers in the corpus. The pattern of changes is consistent. Apply those patterns to the rewrite.
+
+### Variation E: client wants a budget recommendation only
+
+Pull `reference/06-budget-benchmarks.md`. Identify the past winner with the closest profile. Anchor on it. Recommend the budget. Explain the anchor in one sentence to the client.
+
+## A note on probability estimates
+
+When you give a probability estimate (for example "estimated 65 to 75 percent probability of acceptance after fixes"), it should always be a range, not a point estimate. The range communicates honest uncertainty. The range should also be backed by the named past comparables: "we estimate this range because three past dossiers with the same revised profile won in SCF #40 to #42, and two were rejected".
+
+When a client's profile is uniquely strong (For Yield, Rebond with full LOIs), you can go as high as 75 to 85 percent after fixes. When the profile is uniquely weak (anonymous solo dev at max ask), you can go as low as 5 to 15 percent. The vast majority sit between 35 percent and 70 percent. Be honest about the range; it builds the relationship.

package/templates/skills/stellar-scf-grants-advisor/reference/02-scoring-framework.md

@@ -0,0 +1,199 @@
+# The 14-signal scoring framework
+
+Every SCF dossier is scored against 14 signals. Each signal weighs in the panel's review with empirically observable correlation to the final outcome.
+
+For each signal, score the dossier from 1 to 10 where 10 is best in class and 1 is critically weak. The lowest signal is usually the limiting factor.
+
+## Why 14 signals (and not 100, or 5)
+
+Fourteen signals is the number that lets us capture every recurring decision factor in past rounds without producing redundant categories. Below ten, you lose specificity. Above twenty, signals start to overlap and weighting becomes arbitrary.
+
+## The 14 signals
+
+### 1. Team identity (doxxing depth)
+
+What you measure: are every named team member's LinkedIn URLs verifiable, and do they show roles consistent with what the dossier claims? Are GitHub URLs provided for technical roles?
+
+**Score 9 to 10:** all founders fully doxxed, LinkedIn URLs and GitHub URLs verifiable, public credentials match the dossier claims.
+
+**Score 7 to 8:** founders doxxed but missing one piece (no GitHub for CTO, or LinkedIn URL formatted but no https prefix).
+
+**Score 5 to 6:** at least one founder partially anonymous (only handle, no real name) and the dossier asks $100K or more.
+
+**Score 1 to 4:** anonymous-ish team OR clear misrepresentation between dossier claim and verifiable LinkedIn.
+
+Why the panel weighs this: the grant is public money. The panel needs to know who to follow up with if the project goes off the rails. They cannot follow up with a Discord handle.
+
+### 2. Stellar-native traction
+
+What you measure: is there a deployed Soroban testnet or mainnet contract address verifiable on Stellar Expert? Does the dossier name an existing Stellar product live, or is everything "to be built"?
+
+**Score 9 to 10:** contracts already deployed to testnet or mainnet with verifiable addresses.
+
+**Score 7 to 8:** team is Stellar-experienced (prior Stellar projects, Stellar dev community member, Stellar Hackathon).
+
+**Score 5 to 6:** team is crypto-experienced but on other chains (EVM, Solana), Stellar planned but no on-chain artifact yet.
+
+**Score 1 to 4:** zero crypto experience visible.
+
+Why the panel weighs this: this answers "can you actually ship on Stellar?" Demos and screenshots are persuasive; promises are not.
+
+### 3. Budget realism vs scope
+
+What you measure: does the requested budget match the deliverable scope, and is the per-tranche allocation realistic?
+
+**Score 9 to 10:** budget anchored on a named past winner with comparable scope, sub-max ($120K-$135K), structure 3 equivalent tranches.
+
+**Score 7 to 8:** budget reasonable but not anchored, scope clear.
+
+**Score 5 to 6:** budget at $140K-$150K maximum without clear scope justification.
+
+**Score 1 to 4:** maximum $150K ask with a small team or vague scope.
+
+Why the panel weighs this: maximum-ask submissions trigger heightened scrutiny because past rounds have seen abuse. Submissions below the maximum get less skepticism.
+
+### 4. Scope clarity
+
+What you measure: does the integration description name specific Soroban contract files (DealEscrow.rs, YieldVault.rs, GreenBond.rs), specific SCF Integration List items, and a phased timeline?
+
+**Score 9 to 10:** named contracts, named Integration List items, 3 phases with timeline.
+
+**Score 5 to 6:** description is generic, no named contracts or specific items.
+
+**Score 1 to 4:** the description is a wish list of features with no architecture.
+
+Why the panel weighs this: scope clarity is the proxy for execution clarity. Vague descriptions correlate with vague execution.
+
+### 5. Differentiation from previously-funded teams
+
+What you measure: is the dossier in a category where SCF has already funded a similar project recently, and does it explain how it complements rather than duplicates?
+
+**Score 9 to 10:** the dossier explicitly cites past Stellar-funded projects (DeFindex, Aquarius, Blend) and positions as complementary.
+
+**Score 5 to 6:** the dossier is in a recently-funded category but no explicit acknowledgment.
+
+**Score 1 to 4:** direct duplication of an already-funded project.
+
+Why the panel weighs this: SCF wants ecosystem coverage, not redundancy.
+
+### 6. Track choice fit
+
+What you measure: did the dossier pick Integration Track, Open Track or RFP Track correctly?
+
+**Score 9 to 10:** Track choice obviously correct (Integration Track when extending existing primitives, Open Track when net-new).
+
+**Score 5 to 6:** Track choice defensible but could go either way.
+
+**Score 1 to 4:** Track choice mismatched (Open Track for a wrap of existing primitives).
+
+Why the panel weighs this: the wrong Track means the wrong evaluation criteria; reviewers notice when scope and Track don't fit.
+
+### 7. Go-to-market specificity
+
+What you measure: does the GTM plan name specific countries, customer personas, distribution partners, and a credible first-100-users plan?
+
+**Score 9 to 10:** named partners (Black Manta, Brickken, etc.), named first customers (LANGA International, Metz Handball), named user acquisition channel.
+
+**Score 5 to 6:** GTM is described but partners are generic or unnamed.
+
+**Score 1 to 4:** GTM is "we will target [region]" or "for crypto-native users" or any other unspecific phrasing.
+
+Why the panel weighs this: SCF wants to fund projects that will actually find users, not infrastructure that will sit idle.
+
+### 8. Milestone precision
+
+What you measure: do the Build deliverables include specific verifiable evidence (contract IDs, transaction hashes, video walkthroughs, dashboard URLs) and quantified targets (e.g., "$1M AUM", "100 wallets connected", "500 transactions")?
+
+**Score 9 to 10:** each deliverable has a measurable, verifiable evidence requirement.
+
+**Score 5 to 6:** deliverables described but evidence is vague.
+
+**Score 1 to 4:** deliverables described as phases ("Phase 1, Phase 2") without measurable evidence.
+
+Why the panel weighs this: every tranche review depends on the panel being able to verify a deliverable. Unverifiable milestones make every tranche review subjective.
+
+### 9. Traction evidence
+
+What you measure: does Q4 (Abstract) or Q9 (Build) contain verifiable evidence: live URLs, contract addresses on other chains, named pilot customers, signed LOIs, real revenue figures, real user counts?
+
+**Score 9 to 10:** signed LOIs with named entities, real revenue, deployed contracts, named industry recognitions (French Tech, BaFin, etc.).
+
+**Score 5 to 6:** some metrics shared but not externally verifiable.
+
+**Score 1 to 4:** "we are in discussions with X" or "early interest from Y" without any verifiable artifact.
+
+Why the panel weighs this: hand-wavy traction claims correlate strongly with later non-delivery.
+
+### 10. Regulatory framing
+
+What you measure (only for regulated-category dossiers like payments, lending, security tokens, gold, real estate): does the dossier name the specific regulatory framework (Art L.411-2 CMF, MiFID II, MiCA, EP simplifie, PSCA AMF, BIN sponsor, etc.) and the named licensing partner?
+
+**Score 9 to 10:** named framework, named partner, dossier filed proof (For Yield-style PSCA AMF dossier filed).
+
+**Score 5 to 6:** named framework but no named partner.
+
+**Score 1 to 4:** "we will comply" or "subject to regulation" without specifics.
+
+Why the panel weighs this: regulated products without regulatory plans have a near-100 percent failure rate in deployment.
+
+### 11. Open-source posture
+
+What you measure: does the dossier commit to publishing the Soroban contracts under MIT or Apache 2.0?
+
+**Score 9 to 10:** explicit MIT commitment with planned GitHub URL.
+
+**Score 5 to 6:** mention of "open-source" without license specified.
+
+**Score 1 to 4:** no mention of open-source.
+
+Why the panel weighs this: SCF is a public-good fund; reusable primitives are the highest return for the ecosystem.
+
+### 12. Brand non-collision
+
+What you measure: does the project name conflict with a well-known unrelated company (Tessera Labs vs a16z's Tessera, Neon Wallet vs Neo Wallet vs Neon EVM, Solo vs SatoshiPay Solar) that would create SEO confusion or panel mistrust?
+
+**Score 9 to 10:** project name is unique and searchable.
+
+**Score 5 to 6:** mild name overlap but unlikely to cause confusion.
+
+**Score 1 to 4:** direct overlap with a major brand in the same or adjacent vertical.
+
+Why the panel weighs this: panel members do their own Google searches.
+
+### 13. SDF roadmap alignment
+
+What you measure: does the project align with the Stellar Development Foundation's current strategic priorities (x402 micropayments, Protocol 25 X-Ray ZK primitives, EURC adoption, MiCA EU institutional access, agentic payments)?
+
+**Score 9 to 10:** explicit mention of how the project leverages or complements SDF's roadmap.
+
+**Score 5 to 6:** alignment is implicit but not stated.
+
+**Score 1 to 4:** the project would have looked the same with no awareness of SDF roadmap.
+
+Why the panel weighs this: SDF priorities reflect where the foundation wants ecosystem growth.
+
+### 14. Comeback signal (only for reapplying teams)
+
+What you measure (only if the dossier is a reapplication after a previous rejection): does the dossier explicitly acknowledge the prior gap and explain what changed?
+
+**Score 9 to 10:** explicit "we addressed the previous panel's concerns by X".
+
+**Score 5 to 6:** no mention but the changes are visible.
+
+**Score 1 to 4:** no mention and the same gaps remain.
+
+Why the panel weighs this: SCF panels respect teams that learn. They distrust teams that re-submit unchanged dossiers.
+
+## How to use the scores
+
+After scoring all 14, three numbers matter:
+
+1. **Lowest signal**: this is the limiting factor. Fixing this lifts overall probability more than any other action.
+2. **Average score**: gives a rough probability of acceptance (avg 8.0+ = high probability, avg 5.0 to 7.0 = medium, below 5.0 = low).
+3. **Count of signals below 5**: the more sub-5 signals, the more blockers in the dossier.
+
+Always report the lowest signal explicitly in your review. Make the client see what the panel will see.
+
+## A note on weights
+
+The 14 signals are not weighted equally. In practice, signals 1 (team identity), 9 (traction evidence) and 10 (regulatory framing for regulated categories) carry the most weight. A dossier with weak team identity rarely recovers regardless of other strengths. The order in which we list signals is roughly the order of weight.

package/templates/skills/stellar-scf-grants-advisor/reference/03-rejection-patterns.md

@@ -0,0 +1,241 @@
+# Common rejection patterns in past SCF rounds
+
+This document catalogs the twelve recurring patterns that have caused most rejections in SCF rounds #40, #41, #42 and #44. For each pattern, you get:
+
+- The plain-English description.
+- Why SCF panels treat it as a red flag (the mechanism).
+- Specific past rejected dossiers, named, with budget and round.
+- The proven fix.
+
+**Use this document with client-friendly vocabulary.** In your output to clients, never use the term "kill signature". Use phrases like:
+
+- *"This is a recurring rejection pattern we've observed in past SCF rounds."*
+- *"In our database of 130+ rejected dossiers, this is the single most reliable predictor of panel rejection."*
+- *"Three past dossiers were rejected for this exact reason: [names]."*
+
+## Pattern 1: founders not publicly identifiable for a high-ask request
+
+**What it looks like:** the dossier asks $100K or more, but at least one named team member is only identified by a handle (e.g., "DX", "Skyfox"), has no LinkedIn URL, or has no GitHub URL despite being labelled CTO.
+
+**Why panels treat it as a red flag:** the grant is public money. SCF needs to know who to follow up with if the project goes off the rails. Onchain contracts cannot answer that question; only a verifiable real identity can. The panel's mental model is "if something goes wrong, who picks up the phone".
+
+**Past rejected dossiers with this exact pattern:**
+- Sorotrack ($150K in SCF #40, $50K in #41, $50K in #42, rejected all three times), solo dev, only known by handle "Gemy".
+- AION_FI Protocol ($146.5K in SCF #40 PRF), no team disclosed beyond a generic .xyz domain.
+- Tessera Labs ($150K in SCF #42), anonymous team for a regulated category.
+- REAPP ($115K in SCF #42), anonymous x402 implementation.
+- Cicero ($150K in SCF #40 PRF), no team for C++ Soroban project.
+
+**The proven fix:** every named founder gets a verifiable LinkedIn URL added to Q10 before submission. If someone refuses to be publicly identified, reposition them as "core contributor" or "advisor" rather than co-founder. The CTO must have a verifiable GitHub URL.
+
+## Pattern 2: maximum budget ask ($150K) without proportionate scope
+
+**What it looks like:** the dossier requests $145K to $150K but the team is small (1 to 2 people), the deliverable is feature-level rather than primitive-level, and there is no named pilot customer.
+
+**Why panels treat it as a red flag:** the maximum budget triggers heightened scrutiny by design. Reviewers expect the strongest possible justification at the max. When the scope or team does not back the ask, the budget gets cut or the dossier gets rejected entirely.
+
+**Past rejected dossiers with this exact pattern:**
+- reb.cash ($150K in SCF #42), anonymous, no website.
+- Stellar Fintech OS ($140K in SCF #41), generic naming, no team.
+- StellarRead ($150K in SCF #40 PRF), read-to-earn at max budget.
+- Cicero ($150K in SCF #40 PRF), C++ Soroban with no team.
+- Payala ($150K in SCF #40 PRF), 14-year-old unfunded company at max.
+- Paenote ($150K in SCF #40 PRF), Africa B2B at max with only $100K processed.
+- ViFi Labs ($150K in SCF #41), already-funded multi-chain team at max.
+
+**The proven fix:** anchor the budget on a named past winner with comparable profile, then stay 5 to 15 percent below that anchor. The Signal won $121K with 2 co-founders and one escrow contract; Rebond targets $132K with 3 contracts; For Yield targets $144K with an 11-person team and PSCA AMF filing. Place your dossier accordingly.
+
+## Pattern 3: generic project name (category as name)
+
+**What it looks like:** the project name is the literal category ("Stellar Fintech OS", "Soroban Block Explorer"), or contains words like "OS / Platform / Framework / Engine / Hub" with no specific deliverable.
+
+**Why panels treat it as a red flag:** a generic name reads as a generic vision, which reads as a generic execution plan. Specific names communicate specific deliverables.
+
+**Past rejected dossiers with this exact pattern:**
+- Stellar Fintech OS ($140K in SCF #41), collision with Romanian core-banking FintechOS.
+- Stellar Playground v2 ($90K in SCF #40), overlaps with SDF's scaffold-soroban + Stellar Lab + Okashi.
+- Soroban-first Block Explorer ($75K in SCF #41), direct competitor of Rumble Fish ($131K winner).
+- Galactic Playground ($150K in SCF #40), generic name for an established forum.
+- Traction3 / Straction ($55K in SCF #40), "Stellar Growth Engine Infra" with no product.
+- Alzent Digital ($145K in SCF #42), "Wealth Tech Command Center" too abstract.
+
+**The proven fix:** name the specific deliverable and the specific user segment in the project title. "AntevortaCoin: Non-Fungible Gold Certificates on Soroban" beats "Antevorta Gold Platform".
+
+## Pattern 4: brand collision with a well-known unrelated company
+
+**What it looks like:** the project name overlaps with a major brand in a related sector, creating SEO confusion and panel mistrust during their own Google search.
+
+**Why panels treat it as a red flag:** panel members search the project name. If the top results are unrelated companies (a16z's Tessera, Neo blockchain's Neon, US AutoFi Inc.), the panel either gets confused or assumes the project is trying to ride on someone else's brand.
+
+**Past rejected dossiers with this exact pattern:**
+- Tessera Labs (SCF #42) vs Tessera Labs AI (a16z $60M ERP company).
+- Theo: USDC for Haitian Businesses (SCF #44 live) vs theo.xyz Hack VC $20M trading firm.
+- Neon Wallet (SCF #40) vs COZ Neon Wallet (Neo blockchain) AND Neon EVM (Solana).
+- AION_FI Protocol (SCF #40) vs multiple unrelated "Aion" fintechs.
+- Solo (SCF #40 and #44) vs SatoshiPay Solar Wallet (Stellar ecosystem).
+- Stableyard (SCF #40) vs Stables/Stable token.
+- BelugaSwap (SCF #41) vs BSC BelugaSwap (pre-existing).
+- AutoFi (SCF #40, eventually won SCF #41) vs US AutoFi Inc (Kevin Singerman).
+
+**The proven fix:** Google the project name plus "crypto" plus "fintech" before submitting. If the top results are unrelated companies, rebrand or qualify the title (e.g., "Tessera Soroban Labs" instead of "Tessera Labs").
+
+## Pattern 5: existing project on another chain proposes a "Stellar integration" with no Stellar-native engineering history
+
+**What it looks like:** the team is well-established on Solana, EVM or another chain and proposes a port or integration to Stellar without showing any Stellar-specific commitment (no Soroban contract deployed, no Stellar ecosystem partner discussions named, no specific Stellar-only reason).
+
+**Why panels treat it as a red flag:** SCF funds Stellar-native growth, not Stellar bolt-ons that exist to access a grant. The panel wants to fund teams that will stay on Stellar, not teams that are shopping for funding.
+
+**Past rejected dossiers with this exact pattern:**
+- Nuvolari.ai ($84K in SCF #42), Sonic-native AI yield, port to Stellar.
+- $NRG Token by BLOND:ISH ($150K in SCF #41), Solana fan token porting.
+- Nomadz ($150K in SCF #42), Solana travel app.
+- Astrix ($95K in SCF #41), Algorand fan platform porting.
+- WOWMAX ($109K in SCF #41), EVM DEX aggregator.
+- Kima ($133K in SCF #40), multi-chain interop adding Stellar as one of N chains.
+- All Access Fans ($150K in SCF #42), Nigerian Web2 OnlyFans-alt bolt-on.
+- PathPulse AI ($137K in SCF #41 and $128K in SCF #42), computer-vision data network bolt-on.
+
+**The proven fix:** the Q2 Description and Q6 Integration must lead with WHY Stellar specifically (not just "we're multi-chain"). Show a Stellar-native commitment: a Soroban deployed contract address, a named Stellar ecosystem partner discussion, a Stellar-only economic argument that EVM gas would break.
+
+## Pattern 6: duplicates SDF roadmap work
+
+**What it looks like:** the project proposes work that the Stellar Development Foundation is shipping at the protocol level (post-quantum cryptography, ZK primitives, Protocol 25 X-Ray features).
+
+**Why panels treat it as a red flag:** funding redundant work wastes ecosystem resources.
+
+**Past rejected dossiers with this exact pattern:**
+- Nebula Wallet (SCF #41 and #42), wallet-level post-quantum cryptography while SDF explores PQC at protocol layer.
+- zkVault ZK MFA ($130K in SCF #42), wallet-level ZK MFA while Protocol 25 X-Ray ships native ZK primitives.
+- StellaRay ZK Wallets ($80K in SCF #42), same X-Ray duplication.
+- Galeon ($88K in SCF #42 PRF), privacy/compliance tooling overlapping X-Ray.
+- Tessera Labs ($150K in SCF #42), confidential payments duplicating X-Ray rollout.
+- Move-to-Stellar ($115K in SCF #42), alternate VM contradicting SDF's deliberate Rust+WASM choice.
+- Stellar Playground v2 ($90K in SCF #40), duplicates scaffold-soroban + Stellar Lab + Okashi.
+
+**The proven fix:** check SDF's recent roadmap announcements. If your work overlaps, position as a complement (e.g., "leverages Protocol 25 X-Ray primitives to add X") instead of a replacement.
+
+## Pattern 7: overlap with already-funded SCF projects in same or prior round
+
+**What it looks like:** the dossier asks for funding to build what another team already won funding to build.
+
+**Why panels treat it as a red flag:** the same as Pattern 6 but for projects rather than SDF features. The panel curates the ecosystem for coverage, not redundancy.
+
+**Past rejected dossiers with this exact pattern:**
+- Lend.xyz ($120K in SCF #42), RWA real estate while Bando ($75K) won the same round for Mexican RWA.
+- All competing Hummingbot bidders (SCF #41 + #42), three teams bid per round, none won either round.
+- C-Address Toolkit ($120K in SCF #41), lost to Latch + KMP same RFP.
+- StellarScope ($90K in SCF #41), DeFi Positions API RFP, lost to Orion + OctoPos.
+- Soroban-first Block Explorer ($75K in SCF #41), lost to Rumble Fish and OBSRVR Prism.
+- Reactor Trade ($115K in SCF #41), same co-founder as winner Helix Labs same round.
+- Solar ($60K in SCF #40 PRF), Africa unbanked banking, vs TheXBank ($89.5K awarded same round).
+
+**The proven fix:** audit awarded teams in the prior two rounds. If your category is covered, find a sharper sub-niche or pivot.
+
+## Pattern 8: regulated product without a regulatory plan
+
+**What it looks like:** payments, lending, identity, RWA, securities-adjacent product with no jurisdiction-specific compliance plan, no named license partner, and no KYC/AML vendor mentioned.
+
+**Why panels treat it as a red flag:** the panel knows regulated products without regulatory plans almost never ship. They have seen this fail too many times.
+
+**Past rejected dossiers with this exact pattern:**
+- StellarCredit ($55K in SCF #42 PRF), invoice factoring is regulated lending, no plan.
+- AION_FI Protocol ($146.5K in SCF #40), credit cards require BIN sponsors not disclosed.
+- ASGCard ($120K in SCF #42), virtual card issuance for AI agents, no BIN sponsor named.
+- Resolva ($120K in SCF #42), Africa crypto-to-fiat with no license disclosed.
+- Stablpay ($129.1K in SCF #40), regulated stablecoin rail for India, no FIU details.
+- Kyros OS ($135K in SCF #41), Spanish tax compliance, no AEAT/Hacienda partnership.
+- Easner ($150K in SCF #40 PRF), "Stripe for Stablecoins", no banking partner.
+- Goated App ($120K in SCF #41), predictions/gambling, no licensing plan.
+
+**The proven fix:** for any regulated category, the dossier must include jurisdiction, named license partner (or specific license held), KYC/AML vendor, and a "go-to-market without breaking the law" paragraph.
+
+## Pattern 9: vague TAM ("Pan-Africa", "Global", "2 Billion Users")
+
+**What it looks like:** the GTM section flexes a hand-wavy total addressable market with no country sequencing, no first-100-users plan, and no named distribution partner.
+
+**Why panels treat it as a red flag:** vague TAM communicates vague go-to-market execution. The panel has seen many "Pan-Africa" dossiers fail to ship anywhere.
+
+**Past rejected dossiers with this exact pattern:**
+- StellaRay "ZK Wallets for 2 Billion Google Users" ($80K in SCF #42).
+- Joblad "Africa's informal skilled workforce" (SCF #44 live).
+- Azawire "Web3 Banking for Africa" ($80K in SCF #40).
+- Paenote "Africa B2B" ($150K in SCF #40 PRF).
+- MOJA "Group savings for refugees" ($110K in SCF #40 PRF).
+- Resolva "Africa remittance corridors" ($120K in SCF #42).
+- Stableyard "Asia's QR networks" ($119.5K in SCF #40).
+
+**The proven fix:** replace "Africa / Global / Pan-X / N billion users" phrasing with country one, city/segment, specific user persona, and a named partner that gives you that distribution.
+
+## Pattern 10: read-to-earn, learn-to-earn, play-to-earn, fan-token-rewards category
+
+**What it looks like:** the product economic model has consumers earning tokens or rewards for low-effort activities (reading, watching, playing).
+
+**Why panels treat it as a red flag:** post-STEPN and post-Helium panel skepticism. Token-incentive consumer apps have a 100 percent rejection rate in our corpus.
+
+**Past rejected dossiers with this exact pattern:**
+- StellarRead ($150K in SCF #40 PRF), read-to-earn.
+- Gameduk ($60K in SCF #40), gamified EdTech.
+- Stellar Nexus Experience ($60K in SCF #40), XP/badges learn-to-earn.
+- EduAfrica Learning App ($89K in SCF #40), emotional title, learn-to-earn.
+- $NRG Token by BLOND:ISH ($150K in SCF #41), fan token rewards.
+
+**The proven fix:** reframe as "creator royalties" (utility, not speculation) or "verifiable credentials" (provable outcomes), and pair with a non-token revenue source. Or reposition the customer as the protocol (B2B) instead of the user (B2C earning).
+
+## Pattern 11: "Information Collection" status (incomplete dossier)
+
+**What it looks like:** the dossier is incomplete to the point that SCF could not even compile it for panel review. Empty fields, broken thumbnails, missing mandatory items.
+
+**Why panels treat it as a red flag:** they don't. They simply leave the dossier in "Information Collection" status until the team responds, and many teams never respond. The dossier dies without ever being reviewed.
+
+**Past rejected dossiers with this exact pattern:**
+- The Strategists ($150K in SCF #42), Information Collection status.
+- Cushion ($118.4K in SCF #41), Information Collection.
+- Payala to Stellar Integration ($150K in SCF #41), Information Collection.
+- Neon Wallet ($129K in SCF #41), Information Collection.
+- SendbyKatika ($150K in SCF #40), submitted, never passed pre-screen completion.
+
+**The proven fix:** before submitting, walk the entire SCF Build dossier checklist. Verify every mandatory field has content. Pay special attention to thumbnail uploads and URL field formatting.
+
+## Pattern 12: "Panel Review Failed" (explicit panel rejection)
+
+**What it looks like:** the hardest fail. Panel explicitly rejected the dossier (vs falling short on community vote).
+
+**Why panels treat it as a red flag:** they did the rejecting themselves. This is not a pattern you can fix in real time; this is the cluster of all patterns above acting together.
+
+**Cases (high signal):**
+- Sorotrack ($150K in SCF #40 plus $50K in #42).
+- Payala ($150K in SCF #40).
+- StellarRead ($150K in SCF #40).
+- Cicero ($150K in SCF #40).
+- Solar ($60K in SCF #40).
+- MOJA ($110K in SCF #40).
+- Easner ($150K in SCF #40).
+- Riwe ($115K in SCF #40, $96K in #42 also failed).
+- Paenote ($150K in SCF #40).
+- OverSync ($100K in SCF #40).
+- Galeon ($88K in SCF #42).
+- Remitance ($150K in SCF #42).
+- StellarCredit ($55K in SCF #42).
+- PhishGuard ($65K in SCF #40).
+- Offer-Hub ($90K in SCF #40).
+
+**The proven fix:** when a dossier triggered Panel Review Failed, fix the underlying patterns that caused it before reapplying. See `reference/05-comeback-patterns.md` for documented rejected-then-won case studies.
+
+## Quick diagnostic table
+
+Use this when scanning a dossier for the first time:
+
+| Symptom in dossier | Pattern triggered |
+|---|---|
+| Anonymous handle or first name only in Q10 | Pattern 1 (founders not identifiable) |
+| Budget $145K-$150K with small team | Pattern 2 (max ask without scope) |
+| Category words in title (OS, framework, engine, hub) | Pattern 3 (generic name) |
+| Project name matches major unrelated brand | Pattern 4 (brand collision) |
+| "We will deploy on Stellar" with no Soroban testnet | Pattern 5 (bolt-on) |
+| Wallet-level PQC or ZK feature | Pattern 6 (duplicates SDF roadmap) |
+| Same vertical as a recent winner | Pattern 7 (overlap with funded project) |
+| Regulated product, no jurisdiction or license partner | Pattern 8 (no regulatory plan) |
+| "Pan-Africa", "Global", "N billion users" | Pattern 9 (vague TAM) |
+| "Earn rewards by [low-effort activity]" | Pattern 10 (earn-to-X) |
+| Empty mandatory fields | Pattern 11 (Information Collection risk) |
+| Re-submitting identical dossier after prior rejection | Pattern 12 (Panel Review Failed cluster) |