Files
Ready2Blob/.planning/PROJECT.md
T
kawaandClaude Sonnet 4.6 ef0cd94eb7 chore: archive v1.0 milestone — MVP shipped
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>
2026-03-27 15:36:40 +01:00

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

  • scriptTargets filtering: 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:

  • scriptTargets disconnect: 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