stellar-agent 0.1.0 → 0.3.0

package/src/stellar-skills/5-mentorship/stellar-judging-criteria/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: stellar-judging-criteria
+description: 'Reverse-map the build to the hackathon judging rubric and identify gaps before they cost points. Use when the user wants to know how the submission scores against the rubric, what to harden before submission, or how judges will perceive the build.'
+---
+
+# Judging Criteria Alignment
+
+## Purpose
+
+Judges score against a rubric. Teams build against features. This skill closes the gap — for every rubric criterion, identify what in the build wins it (and what's missing).
+
+## On Activation
+
+Load:
+- `{planning_artifacts}/hackathon-brief.md` (must exist — recommend `IS` and `MV` first if missing)
+- Hackathon URL if provided to Pera — fetch the official rubric
+
+If no rubric is available, use the generic Stellar judging rubric below.
+
+## Workflow
+
+### Step 1: Confirm the Rubric
+
+Pull the official rubric from the hackathon page if known. Otherwise use:
+
+| Criterion | Default weight | What judges look for |
+|---|---|---|
+| Innovation | 25% | "Have we seen this before on Stellar?" |
+| Technical implementation | 25% | Soroban depth, code quality, test coverage |
+| Business / impact | 25% | Who pays, how big, distribution path |
+| Demo quality | 25% | Recording, narration, on-chain proof |
+
+Show the user the rubric and confirm before proceeding.
+
+### Step 2: Reverse-Map the Build
+
+For each criterion, ask: *"What specifically in our build wins this?"*
+
+Produce a table:
+
+```markdown
+## Rubric alignment
+
+| Criterion | Weight | How our build wins it | Score self-assessment |
+|---|---|---|---|
+| <criterion> | <%> | <specific feature, code path, or asset> | <strong | medium | weak> |
+| <criterion> | <%> | <specific feature, code path, or asset> | <strong | medium | weak> |
+```
+
+Rules:
+- "How our build wins it" must be **specific**. Not "good architecture" — name the contract, the function, the storage tier.
+- Self-assessment is honest. Mark `weak` if it's not the team's strongest answer.
+
+### Step 3: Identify Gaps
+
+For every criterion marked `weak` or `medium`:
+
+```
+GAP: <criterion>
+Cost to close: <hours>
+Easiest win: <one specific action — write a test, polish a screen, record a 30s segment>
+```
+
+Sort the gaps by `weight × (target_score − current_score)` — biggest expected-points-gain first.
+
+### Step 4: Recommend Spend
+
+If the team has buffer time left from `MV`:
+
+- Apply the buffer to the top gap until either:
+  - The gap closes, or
+  - The buffer runs out
+- If the buffer runs out with gaps remaining, the team is over-scoped. Move a nice-to-have to skip and recompute.
+
+### Step 5: Stellar-Specific Hardening
+
+These items move scores noticeably on most Stellar hackathon rubrics. Check each:
+
+| Item | Why it matters | How to check |
+|---|---|---|
+| Contract has at least one passing test | Technical implementation | `cargo test` from contract dir |
+| Deployed to testnet with a successful tx | Demo quality | Have a `stellar.expert` link in README |
+| README has install + run instructions | Technical implementation | A judge can clone and run in < 5 min |
+| Uses a Soroban primitive non-trivially | Innovation | Custom storage type, cross-contract call, auth pattern, etc. |
+| `stellar.toml` configured (if custom asset) | Real-world fit | File exists, served at root |
+| At least one SEP referenced (10/24/31/41) | Innovation + real-world fit | Even mentioning SEP-10 auth in README counts |
+
+For each item failing, log it as a gap with a cost estimate.
+
+### Step 6: Save and Confirm
+
+Append to `{planning_artifacts}/hackathon-brief.md` as a `## Rubric alignment` section.
+
+Show the user the top 3 gaps. Ask: *"Closing these — or accepting and moving on?"*
+
+## The 80/20 of judging
+
+Across hackathons, two things move the needle disproportionately:
+1. **Demo quality** — a 90s recording with clean narration outperforms 2 extra features.
+2. **README clarity** — judges who can't run the project skim the README; clear READMEs convert skim-judges into engaged judges.
+
+If forced to pick between closing a technical gap or polishing the demo + README, polish wins almost every time.
+
+## Anti-patterns to flag
+
+- **"We'll add tests after submission."** — Tests are evidence of technical depth. Even one passing test changes the perception.
+- **"The demo speaks for itself."** — It doesn't. Narration carries 50% of demo quality.
+- **"We don't need a README — the code is self-documenting."** — Judges don't read code first. README is the front door.
+- **"Let's add another feature instead of polishing."** — One polished feature outscores three half-finished ones every time.
+
+## Output
+
+Updates `{planning_artifacts}/hackathon-brief.md` with rubric alignment table, gap list with costs, and recommended spend.
+
+## Next Steps
+
+- `stellar-demo-prep` (DM) — turn the gaps into a recording plan
+- `stellar-pitch-coaching` (PC) — sharpen the narration
+- `stellar-submission-prep` (SP) — once gaps are closed, run the submission checklist

package/src/stellar-skills/5-mentorship/stellar-mvp-definition/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: stellar-mvp-definition
+description: 'Split the hackathon feature list into must-have, nice-to-have, and skip — with hour estimates and a buffer rule. Use when the user needs to cut scope, knows what they want to build but not what to drop, or is asking whether something will fit in the timebox.'
+---
+
+# MVP Definition
+
+## Purpose
+
+Turn the brief into a buildable plan that fits the timebox with buffer. Anything in the "skip" column is not discussed again — it's a forcing function against feature creep.
+
+## On Activation
+
+Load `{planning_artifacts}/hackathon-brief.md`. Resolve `{network_preference}` and `{primary_language}` from config.
+
+If no brief exists, recommend running `IS` (Idea Scoping) first.
+
+## Workflow
+
+### Step 1: Enumerate All Features
+
+Ask the user to list every feature they're imagining for the demo. Don't filter yet. Capture all of them. Aim for 8–15 items.
+
+### Step 2: Estimate Each Feature in Hours
+
+For each feature, ask: *"If a skilled Stellar dev built only this, how many hours?"*
+
+Use these rules of thumb for calibration:
+
+| Feature class | Hours (skilled Stellar dev) |
+|---|---|
+| New Soroban contract function with tests | 2–4 |
+| Contract deploy + initialization scripts | 1–2 |
+| Freighter connect + sign in React | 1–2 |
+| Next.js page with Stellar SDK calls | 1–3 |
+| Custom asset creation + trustline | 1 |
+| SEP-10 auth flow | 3–5 |
+| Anchor integration (SEP-24 / SEP-31) | 4–8 |
+| Storage migration / contract upgrade | 3–6 |
+| Tailwind dashboard with charts | 2–4 |
+| Demo recording + narration | 1 |
+| Pitch deck | 1–2 |
+| README + repo polish | 0.5–1 |
+
+Multiply by 1.5 for an inexperienced team. By 2 for a first-time Stellar team.
+
+### Step 3: Apply the Cut
+
+Build a three-column table:
+
+```markdown
+## MVP cut
+
+| Must-have (build first) | Nice-to-have (only if ahead) | Skip (do not start) |
+|---|---|---|
+| <feature> — <hours> | <feature> — <hours> | <feature> |
+| <feature> — <hours> | <feature> — <hours> | <feature> |
+| <feature> — <hours> |   |   |
+
+**Total must-have hours:** <X>
+**Build window:** <Y>
+**Buffer:** <Y − X> hours (<percentage>%)
+```
+
+### Step 4: The 25% Buffer Rule
+
+Apply this rule mechanically:
+
+- If `buffer < 25%` of build window → move the bottom must-have to nice-to-have.
+- If `buffer < 10%` → move two items down. Idea is still too big.
+- If `buffer ≥ 50%` → the idea is too small. Promote one nice-to-have OR plan for polish (better demo, tighter UX).
+
+No exceptions. The buffer rule is non-negotiable because it absorbs three categories of cost the team always underestimates: debugging time, testnet flakiness, and recording retakes.
+
+### Step 5: Mark the Demo Path
+
+In the must-have column, prefix each item that's on the critical demo path with `🎯`:
+
+```
+🎯 Connect Freighter wallet — 1h
+🎯 Sign Soroban contract call — 2h
+   Display contract state — 1h
+🎯 Show stellar.expert tx link — 0.5h
+```
+
+Critical demo path items must finish first. Everything else is optional, even if it's marked must-have.
+
+### Step 6: Define the Fallback
+
+Ask: *"If 30% of the build window evaporates, what does the demo look like?"*
+
+Write the fallback below the cut table:
+
+```markdown
+## Fallback (if 30% of time is lost)
+
+- Drop: <item>
+- Demo flow shortened to: <one sentence>
+- Hero moment preserved? <yes / no — if no, the cut is wrong>
+```
+
+If the hero moment isn't preserved, the cut needs to be re-done.
+
+### Step 7: Save
+
+Append to `{planning_artifacts}/hackathon-brief.md` under a `## MVP cut` heading. Confirm with the user before proceeding.
+
+## Anti-patterns to flag
+
+- **"We can always add it later if we have time."** — That's what nice-to-have is for. Don't blur the columns.
+- **"This is must-have because it's important."** — Important ≠ must-have for the demo. Critical demo path is the only test.
+- **"Auth has to be real."** — Hackathon judges rarely test auth. Hardcoded wallet is fine for the demo.
+- **"We need a database."** — Soroban storage + an in-memory cache usually covers it. Real DBs eat 4–6 hours of setup.
+- **"We need a mobile app."** — Web demo first. Mobile is a v2.
+
+## Output
+
+Updates `{planning_artifacts}/hackathon-brief.md` with the cut table, buffer math, demo path markers, and fallback.
+
+## Next Steps
+
+- `stellar-judging-criteria` (JC) — map the must-haves to the rubric
+- `@stellar-agent-architect` (Nova) — lean architecture for the must-haves
+- `@stellar-agent-developer` (Sol) — start `IC` once the cut is locked

package/src/stellar-skills/5-mentorship/stellar-pitch-coaching/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: stellar-pitch-coaching
+description: 'Build the hackathon pitch — 3-minute deck outline, elevator pitch, and judge Q&A drill. Use when the user needs a pitch deck, has to present live to judges, or wants to rehearse common judge questions before submission.'
+---
+
+# Pitch Coaching
+
+## Purpose
+
+Most submissions fail the pitch even when the build is strong. Judges spend 3 minutes per team — a tight pitch sells the build before they have time to inspect the code. This skill produces the four-beat pitch, the deck outline, and the Q&A drill.
+
+## On Activation
+
+Load:
+- `{planning_artifacts}/hackathon-brief.md` — for problem, solution, hero moment
+- `{implementation_artifacts}/demo-storyboard.md` — the recorded demo
+
+Recommend running `DM` (Demo Prep) first if no demo exists.
+
+## Workflow
+
+### Step 1: The Four-Beat Pitch (3 minutes)
+
+Every pitch has the same four beats. Time them strictly.
+
+```markdown
+## Pitch (3:00)
+
+### Beat 1 — Problem (0:30)
+- Who hurts. How often. What they lose today.
+- One sentence, one statistic, one human detail.
+- Avoid: "blockchain", "web3", "trustless" — these are jargon, not problem statements.
+
+### Beat 2 — Solution + Demo (1:30)
+- One sentence on what you built.
+- Play the recorded demo.
+- The demo carries this beat — don't talk over it.
+
+### Beat 3 — Why now / Why Stellar (0:30)
+- What changed that makes this possible now.
+- What Stellar primitive makes this work that wouldn't on another chain.
+- Cite one specific Stellar feature: Soroban contract, anchors, SEP-10, custom assets, low fees.
+
+### Beat 4 — Ask (0:30)
+- Where the repo is (GitHub URL).
+- Where the contract lives (testnet contract ID).
+- What's next: mainnet date, a specific partner, a specific mentor intro.
+- A specific ask beats a generic one. "We want feedback on our auth model from anyone who's shipped SEP-10" > "We want feedback".
+```
+
+### Step 2: The Elevator Pitch (15 seconds)
+
+For the hallway / Discord intros. Stricter than Beat 1.
+
+Format:
+```
+We built <thing> on Stellar. It lets <user> <verb> <object>, which currently <pain>. Built in <hours>h, deployed on testnet.
+```
+
+Example:
+```
+We built a payroll dApp on Stellar. It lets remote teams pay contractors in USDC across borders in under 5 seconds, which currently takes 3 days through Wise. Built in 48h, deployed on testnet.
+```
+
+Drill this until it's automatic. The user should be able to deliver it without thinking.
+
+### Step 3: Deck Outline (Optional — Some Hackathons Require)
+
+If the hackathon requires a slide deck, use this 7-slide template. Keep slides visual, not text-heavy.
+
+| # | Slide | Content | Time |
+|---|---|---|---|
+| 1 | Title | Product name · team handles · one-line tagline | 5s |
+| 2 | Problem | One image · one statistic · one sentence | 25s |
+| 3 | Solution | Screenshot of the dApp · one sentence | 20s |
+| 4 | Demo | Video embed (autoplay) OR static "Demo →" pointer | 90s |
+| 5 | Why Stellar | One diagram · key primitive(s) used | 25s |
+| 6 | Ask | Repo URL · contract ID · what's next | 20s |
+| 7 | Team | Names, handles, what each person built | 5s |
+
+Tools: Pitch.com, Slides.app, Google Slides, or a single-page HTML deck. Don't waste hackathon time on slide design — content over polish.
+
+### Step 4: Judge Q&A Drill
+
+Judges ask predictable questions. Drill answers in under 30 seconds each.
+
+#### Always-asked
+
+- **"What stops a competitor from copying this in a week?"**
+  - Answer pattern: distribution, data moat, or a specific technical hurdle (e.g., "we use a custom Soroban storage pattern that took us 30h to design").
+- **"Why on-chain instead of a Postgres table?"**
+  - Answer pattern: censorship resistance, composability, public verifiability, or the specific reason settlement on Stellar beats settlement off-chain (low fees, fast finality, anchors).
+- **"What's the cost per user on mainnet?"**
+  - Pull real numbers: Soroban resource fees, Horizon RPC costs, Anchor fees. Have a per-tx cost ready.
+- **"Who's your first paying customer?"**
+  - A specific company name or persona is better than a market segment.
+- **"How big is the market?"**
+  - One number + the source. No range. No "billions" without citation.
+
+#### Track-specific
+
+| Track | Common questions |
+|---|---|
+| DeFi | "What's your TVL plan?" · "Liquidity bootstrap strategy?" · "Composability with which protocols?" |
+| Payments | "Anchor relationships?" · "Compliance posture?" · "FX/spread economics?" |
+| Identity | "How does this comply with GDPR / CCPA?" · "Sybil resistance?" |
+| Gaming | "Player retention curve?" · "Tokenomics balance?" |
+| RWA | "Legal structure for the tokenized asset?" · "Oracle for off-chain price?" |
+
+For each, write a one-paragraph answer. Drill until it's automatic.
+
+#### Killer follow-up
+
+- **"What's the worst thing about your build right now?"**
+  - This catches teams that pretend everything is perfect. A honest answer ("we don't have tests yet — we'd add them before mainnet") scores higher than deflection.
+
+### Step 5: Live-Pitch Hygiene
+
+- **Stand up if Zoom-pitching.** Energy translates to camera.
+- **One person pitches.** Multi-person pitches lose 30 seconds to handoffs.
+- **Don't read slides.** Slides are visual support, not the script.
+- **Keep your eyes on the camera, not the chat window.**
+- **Have repo URL + contract ID on screen for Beat 4.** Judges screenshot it.
+
+### Step 6: Save
+
+Save artifacts to:
+- `{planning_artifacts}/pitch-script.md` — four-beat script with timing
+- `{planning_artifacts}/elevator-pitch.md` — 15s version
+- `{planning_artifacts}/judge-qa.md` — drilled answers to common questions
+
+Recommend the user rehearse the pitch 3 times before submitting, with a stopwatch.
+
+## Anti-patterns to flag
+
+- **Opening with "We're [team name] and we built…"** — Cut the team intro to the end. Open with the problem.
+- **Spending 90 seconds on the team.** Save it for Q&A.
+- **Reading the README on screen.** Judges can read. Talk over the demo, don't recite the README.
+- **"This is just an MVP."** — Never apologize. Frame as "this is the shipped version of v1".
+- **Vague asks.** "We'd love feedback" is not an ask. Name a specific thing.
+
+## Output
+
+- `{planning_artifacts}/pitch-script.md`
+- `{planning_artifacts}/elevator-pitch.md`
+- `{planning_artifacts}/judge-qa.md`
+
+## Next Steps
+
+- `stellar-submission-prep` (SP) — final checklist before hitting submit

package/src/stellar-skills/5-mentorship/stellar-submission-prep/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: stellar-submission-prep
+description: 'Final pre-submission checklist for Stellar/Soroban hackathons — repo polish, README, demo video, deployed testnet, contract IDs, Devpost/SCF/SDF form. Use when the user is in the last 2 hours before deadline, ready to hit submit, or verifying the submission is complete.'
+---
+
+# Submission Prep
+
+## Purpose
+
+Run the final checklist in the last 2 hours before submission. Catch the 5-minute fixes that cost the team a track win — missing testnet contract ID in README, demo video not uploaded, repo still private, team members not invited to Devpost.
+
+## On Activation
+
+Load:
+- `{planning_artifacts}/hackathon-brief.md`
+- `{implementation_artifacts}/demo-storyboard.md`
+- `{implementation_artifacts}/deployed-contracts.md` (if it exists)
+
+Check the submission deadline. Surface hours remaining at the top of the response.
+
+## Workflow
+
+### Step 1: Surface Hours Remaining
+
+```
+⏳ Hours remaining: <X>
+
+Recommended order for last 2h:
+  T-2:00  →  Repository polish
+  T-1:30  →  README final pass
+  T-1:00  →  Demo video uploaded
+  T-0:30  →  Submission form
+  T-0:15  →  Buffer for re-submission
+```
+
+If hours remaining < 0.5, skip non-critical items. Get the submission in first; polish after if time allows.
+
+### Step 2: Repository Checklist
+
+```markdown
+## Repository
+
+- [ ] Public GitHub repo (not private — judges can't see private repos)
+- [ ] Default branch is `main` and reflects the submitted code
+- [ ] Repo URL has been tested in an incognito window
+- [ ] `LICENSE` file present (MIT or Apache-2.0 is the safe default)
+- [ ] `.gitignore` excludes: `target/`, `node_modules/`, `.env`, `*.wasm`, keypair files
+- [ ] No secrets committed — grep for: `PRIVATE_KEY`, `S...` (raw secrets), `password`, `api_key`
+- [ ] All team members are repo collaborators (or visibly active in commits)
+- [ ] Last commit is from a hackathon-time window (judges check timestamps)
+```
+
+If the repo is currently private, **make it public now**. Some hackathons disqualify private submissions outright.
+
+### Step 3: README Checklist
+
+The README is the front door. A judge who can't run the project in 5 minutes moves on.
+
+```markdown
+## README must include
+
+- [ ] One-line pitch at the top (`# <Project name>` + tagline)
+- [ ] One screenshot or GIF in the first scroll height
+- [ ] Demo video link (unlisted YouTube or hosted MP4)
+- [ ] Live demo URL (if web-accessible) OR a "try it" section
+- [ ] Install + run instructions a judge can copy-paste
+- [ ] Testnet contract ID(s) with `stellar.expert` link
+- [ ] At least one successful tx hash linked from `stellar.expert`
+- [ ] Built-with stack (Soroban, Stellar SDK, Next.js, etc.)
+- [ ] Team section with handles
+- [ ] License
+```
+
+#### README template skeleton
+
+```markdown
+# <Project name>
+
+> <One-sentence tagline>
+
+![<Screenshot>](docs/screenshot.png)
+
+**Demo video:** <youtube link>
+**Live demo:** <url>
+**Testnet contract:** [`<CONTRACT_ID>`](https://stellar.expert/explorer/testnet/contract/<CONTRACT_ID>)
+**Example tx:** [`<TX_HASH>`](https://stellar.expert/explorer/testnet/tx/<TX_HASH>)
+
+## Problem
+
+<2–3 sentences>
+
+## Solution
+
+<2–3 sentences>
+
+## How it works
+
+<3 bullets describing the on-chain flow>
+
+## Install
+
+\`\`\`bash
+git clone <repo>
+cd <repo>
+npm install   # or: cargo build --target wasm32-unknown-unknown --release
+cp .env.example .env
+npm run dev
+\`\`\`
+
+## Stack
+
+- Soroban smart contracts (Rust)
+- @stellar/stellar-sdk (TypeScript)
+- Next.js App Router
+- Freighter wallet
+
+## Team
+
+- <Name> (@handle) — <what they built>
+
+## License
+
+MIT
+```
+
+### Step 4: On-Chain Verification
+
+```markdown
+## On-chain checklist
+
+- [ ] Contract deployed to testnet — record contract ID in README
+- [ ] Contract initialized (`initialize` or equivalent) — verify with `stellar contract invoke ... -- get_*`
+- [ ] At least one successful tx hash linked from README
+- [ ] If using a custom asset: issuing account + trustline tx hash documented
+- [ ] If using SEP-10: auth endpoint live and returning valid JWTs
+```
+
+Quick verification commands:
+```bash
+# Confirm contract is alive
+stellar contract invoke \
+  --id <CONTRACT_ID> \
+  --network testnet \
+  -- <view_function>
+
+# Confirm a tx
+curl -s "https://horizon-testnet.stellar.org/transactions/<TX_HASH>" | jq '.successful'
+```
+
+### Step 5: Demo Video Checklist
+
+```markdown
+## Demo video
+
+- [ ] Recorded at 1080p+ (1920×1080 minimum)
+- [ ] Length: 60–180s (check hackathon spec)
+- [ ] Audio narration audible (no static, no clipping)
+- [ ] Uploaded to YouTube as **unlisted** (NOT private — judges can't see private)
+- [ ] OR hosted on Vimeo / direct MP4 — link works in incognito
+- [ ] Linked from README
+- [ ] Linked from submission form
+- [ ] Thumbnail is a meaningful frame (not black, not the OS desktop)
+```
+
+### Step 6: Submission Form Checklist
+
+The exact form depends on the platform (Devpost, SCF, SDF, Discord). Common fields:
+
+```markdown
+## Submission form
+
+- [ ] Project title (matches repo name)
+- [ ] Tagline (one sentence)
+- [ ] Description (2–3 paragraphs — pull from README)
+- [ ] Built-with tags include: `stellar`, `soroban`, language stack, frameworks
+- [ ] Track selection confirmed (from `TR` recommendation)
+- [ ] GitHub URL
+- [ ] Demo video URL
+- [ ] Live demo URL (if applicable)
+- [ ] Testnet contract ID in the body
+- [ ] Team members invited and they have **accepted** the invite (Devpost especially — unaccepted invites disqualify)
+- [ ] Selected for the right hackathon (verify the URL on the submission page)
+- [ ] Submission saved as draft once, then submitted (in case of platform error)
+```
+
+### Step 7: Final Sanity Checks
+
+Before hitting "Submit":
+
+- [ ] Open the GitHub repo in an incognito window — it loads, README renders
+- [ ] Click the demo video link in incognito — it plays
+- [ ] Click the testnet contract link in incognito — stellar.expert shows the contract
+- [ ] Submission form preview matches what's in your README
+
+### Step 8: Submit and Confirm
+
+After submission:
+- [ ] Screenshot the "Submission received" page
+- [ ] Confirmation email received (check spam)
+- [ ] Submission visible on the public hackathon submission page (some platforms have a delay)
+
+If anything fails, you have the buffer window in Step 1 to fix and resubmit.
+
+### Step 9: Sign-off
+
+Pera signs off when the checklist is green:
+
+> "Submitted. Hands off the keyboard. Get sleep."
+
+Add a `## Submission` section to `{planning_artifacts}/hackathon-brief.md` capturing:
+- Final submission timestamp
+- Submission URL
+- Track submitted
+- Confirmation screenshot path
+
+## Anti-patterns to flag
+
+- **Submitting at T-0 minutes.** Always submit at T-30 minimum. Platforms get flaky under deadline load.
+- **Private repos / private videos.** Disqualifies the submission silently.
+- **Unaccepted team invites.** Some platforms (Devpost) only credit accepted team members.
+- **Submitting and then pushing more commits.** The submission snapshot is what's judged. Don't introduce regressions after submitting.
+- **Skipping the incognito test.** Cookies hide private/draft state. Always verify in incognito.
+
+## Output
+
+- Final state of `{planning_artifacts}/hackathon-brief.md` with `## Submission` section
+- All checklist items confirmed before final submit
+
+## Next Steps
+
+After submission:
+- Get sleep.
+- Prepare for live judging Q&A — review `{planning_artifacts}/judge-qa.md` if a live round is scheduled.
+- Plan a mainnet follow-up only after the team has rested.