Extended interactive playground with guided send flow

[truthixify]

Tier: L (5-7 days) | Type: feature

Context. Wave 7 landed a scan-only playground (scripts/playground/) embedded in the quickstart. Readers ask for a next step: derive a stealth key, construct a mock announcement, then scan it themselves. Turning the playground into a multi-step guided flow (derive → send → scan → withdraw) with fixture assets teaches the mental model without any wallet or network dependency.

Scope.

• Extend scripts/playground/ with three new steps and a stepper UI.
• Fixture Horizon-shaped events served from a static JSON file.
• Each step embeds inline in the relevant docs page (stellar-quickstart.mdx first step, stealth-keys.mdx derive step, fetch-announcements-stream.mdx scan step).
• Entirely client-side, no network calls, CSP-safe (iframe sandbox allow-scripts only).
• Reset button per step, share-a-permalink for a given state.

Acceptance.

• All four steps run inline on their host pages
• Zero external requests during any step (verified in DevTools network tab)
• Renders in mint dev
• Passes Compile docs snippets CI
• Playwright smoke test covers the full flow in scripts/playground/tests/

Files. scripts/playground/ (extend), guides/stellar/stellar-quickstart.mdx, api-reference/stealth-keys.mdx, api-reference/fetch-announcements-stream.mdx.

[Mathew2k-hash]

@Mathew2k-hash has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I'd like to work on this issue because it combines frontend development, documentation UX, and testing—areas I'm comfortable with. I understand the requirements and plan to extend the existing playground with a guided four-step flow, fixture-based data, permalink support, and Playwright coverage while ensuring everything remains fully client-side and CSP-safe. I'm confident I can deliver a clean, well-tested implementation that meets all acceptance criteria.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Mathew2k-hash to this issue.

[retkatmun]

@retkatmun has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer,

I’m a smart contract and full-stack developer and would love to contribute to this issue. I’m an experienced contributor with hands-on expertise in Rust, Soroban, Cairo, and TypeScript.

I’m passionate about building secure, scalable blockchain solutions, with a strong emphasis on writing clean and maintainable code. Based on the scope of this issue, I’m confident I can deliver a complete solution within 24 hours of assignment.

I’d greatly appreciate the opportunity to contribute and help move this forward.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @retkatmun to this issue.

[best2025j]

@best2025j has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello maintainer, i will like to work on this task please assign to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @best2025j to this issue.

[gbengaeben]

@gbengaeben has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello maintainer,

I would like to contribute to issue #134 ("Extended interactive playground with guided send flow") for the wraith-protocol/docs repository.

To help me implement this feature cleanly and ensure it meets all architecture and acceptance criteria (multi-step client-side stepper UI, fixture-driven Horizon-shaped events, inline doc page embedding, zero network requests, and Playwright test coverage), could you clarify or confirm a few details?

1. Architecture & Bundling: Since this extends scripts/playground/, should the new steps be built as modular vanilla JS/TS components or integrated into the existing framework within that directory? Are there specific UI libraries or CSS frameworks already utilized in the playground that I should stick to?
2. Fixture Structure: For the static JSON fixture serving Horizon-shaped events, is there an existing schema convention or sample payload in the codebase I should model the mock announcements and transactions after?
3. Playwright Setup: Are the Playwright smoke tests in scripts/playground/tests/ configured to run headlessly out of the box with standard CI configurations, or are there custom environment setup steps I should be aware of?

Once aligned, I'm ready to start working on extending the playground, updating the respective .mdx guides, and adding the required test coverage. Looking forward to your guidance

ℹ️ Repo Maintainers: To accept this application, review their application or assign @gbengaeben to this issue.

[drips-wave]

Congratulations, @gbengaeben! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @gbengaeben: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[truthixify]

Assigned. Answers to your three questions:

1. Architecture and bundling. scripts/playground/ is deliberately dependency-free: index.html plus plain ES modules (scanner.js), no framework, no build step, no CSS framework. Keep it that way. The stepper should be vanilla JS in the same style. The constraint that matters is the CSP in the docs site, so no external script or style sources, everything inline or same-origin.

2. Fixture structure. scripts/playground/generate-fixtures.mjs is the existing generator and its output is the schema to model. Match Horizon's contract-event shape as it is consumed in src/chains/stellar/announcements.ts in the sdk repo, which is what real callers parse. Extend the existing generator rather than hand-writing a second fixture format.

3. Playwright. There is no Playwright setup under scripts/playground/ yet, so you are creating it, not inheriting it. Headless with the default config is fine. Serve the playground over a static file server in the test rather than file://, because module imports and the CSP behave differently on file://.

One thing not in the issue text that is worth knowing: the acceptance item about zero external requests is the real gate. Verify it in the Playwright run by failing the test on any request to a non-local origin, rather than checking by hand in DevTools.