4 phases, 18 plans, 24/24 requirements, 98 tests GREEN. Archived ROADMAP + REQUIREMENTS to milestones/. ROADMAP collapsed. PROJECT.md evolved with validated requirements and key decisions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.3 KiB
Ready2Blob
What This Is
Ready2Blob is a pure-frontend web app that helps IT professionals deploy rclone onto end-user Windows PCs. A step-by-step wizard collects backend credentials (Azure Blob, S3, S3-compatible) and deployment preferences, then generates rclone config files and PowerShell scripts ready to push via Intune or any RMM tool — all client-side, no server required.
Core Value
An IT pro can go from zero to a deployable rclone setup in minutes — without needing to know rclone's config syntax or PowerShell deployment conventions.
Requirements
Validated
- ✓ Multi-step wizard guides user through rclone backend selection and configuration — v1.0
- ✓ Supports Azure Blob, S3, and S3-compatible backends — v1.0
- ✓ Generates a valid rclone.conf file with live preview — v1.0
- ✓ Generates PowerShell deployment script for MS Intune (Intune install + detection scripts) — v1.0
- ✓ Generates PowerShell deployment script for RMM tools (generic SYSTEM-context) — v1.0
- ✓ User can download each output file individually or as a ZIP bundle — v1.0
- ✓ Includes rclone installation step in scripts (toggleable) — v1.0
- ✓ All config generation runs client-side (no backend, static site) — v1.0
- ✓ Security warning gate before any download — v1.0
- ✓ Wizard state never written to localStorage or sessionStorage — v1.0
Active
scriptTargetsfiltering: only render output blocks for selected Intune/RMM targets (tech debt TD-1)- ReviewStep Back button (UX consistency with other steps — tech debt TD-2)
- Backend list in BackendSelectionStep driven by BACKEND_REGISTRY keys (maintainability — tech debt TD-4)
- Additional backends: OneDrive, SFTP, Google Cloud Storage, Backblaze B2
- Field-level format validation per backend (Azure account name format, S3 region codes)
- Explanatory tooltips on sensitive fields (SAS token vs access key, region codes)
Out of Scope
- User accounts / saved templates — no backend, no persistence
- Server-side generation — everything runs in the browser
- Test connection / validate credentials — requires backend proxy (CORS blocks direct cloud API calls)
- rclone version management / auto-update on endpoints — separate lifecycle problem
- Non-Windows targets — scripts target Windows endpoints only
- Auto-push to Intune via Graph API — requires Azure AD app registration, massive scope increase
- Config credential encryption — rclone encrypted configs require interactive unlock, incompatible with unattended deployment
Context
Shipped: v1.0 — 2026-03-26/27, 2 days, 4 phases, 18 plans, ~2,746 LOC TypeScript/TSX Tech stack: Vite 6, React 18, TypeScript 5, Tailwind v4, react-hook-form 7, Zod 4, Vitest 4, JSZip Test coverage: 98 tests across 12 test files — all GREEN
Known issues / tech debt:
scriptTargetsdisconnect: user can deselect Intune or RMM in DeploymentStep but all blocks still appear in ReviewStep- ReviewStep lacks a Back button; users navigate back via StepIndicator breadcrumb only
- BackendSelectionStep BACKENDS constant is hardcoded — adding to BACKEND_REGISTRY does not auto-surface in UI
- 6 browser verifications still pending (live preview reactivity, real file writes, ZIP content, clipboard, DevTools storage check)
Constraints
- Architecture: Pure static frontend — no backend, no server required
- Target OS: Windows endpoints only (scripts are PowerShell)
- Secrets: Plain text in generated files — UI must display a clear security warning before download
Key Decisions
| Decision | Rationale | Outcome |
|---|---|---|
| Pure frontend (no backend) | Simpler hosting, no data retention risk with credentials | ✓ Good — static site deployable anywhere |
| BACKEND_REGISTRY as single source of truth | Drives form rendering, Zod schemas, and config generation from one definition | ✓ Good — zero duplication across phases |
| useReducer + Context API (no external state lib) | Zero dependencies, sufficient for 4-step wizard | ✓ Good — kept bundle lean |
| Wave 0 TDD (stubs RED before implementation) | Forces API contract before code, catches integration mismatches early | ✓ Good — caught several issues upfront |
| Support all rclone backends (not Azure-only) | Broader utility despite "Blob" in project name | ✓ Good — S3-compatible covers Wasabi/MinIO/R2 |
| Optional rclone install in scripts | Different orgs have different baseline images | ✓ Good — no friction for orgs that pre-install |
| Tailwind v4 via @tailwindcss/vite plugin | No postcss.config.js, no tailwind.config.js needed | ✓ Good — cleaner config |
| Zod v4 + @hookform/resolvers v5 together | v5 resolvers required for Zod v4 compatibility | ✓ Good — noted for future upgrades |
| AzureAuthToggle uses CSS hidden (not conditional render) | Preserves both sas_url and key in react-hook-form state when toggling | ✓ Good — avoids field reset on toggle |
| scriptTargets defaults to both ['intune','rmm'] | Users deselect rather than discover — less friction | — Pending (deferred filtering to v1.1) |
| BACKEND_REGISTRY keys not wired to UI list | Hardcoded BACKENDS constant in BackendSelectionStep | ⚠️ Revisit — maintainability gap for v1.1 |
Last updated: 2026-03-27 after v1.0 milestone