Phase 1 – Homepage & Signup Validation
Owner: Founder | Responsible: UX + Content + Dev + QA
Pending
1.1 Homepage Messaging
(UX + Founder)
Pending
Clear value proposition visible.
Expected behaviour: Visitor sees one main headline explaining platform value within 5 seconds; no clutter.
No technical jargon used.
Expected behaviour: Copy uses plain language; terms like "no-code", "deploy" explained or avoided for first-time visitors.
Explains build/deploy/manage simply.
Expected behaviour: Three pillars (build, deploy, manage) or equivalent communicated in one glance.
5-second comprehension test passed.
Expected behaviour: User can state what the product does after 5 seconds on the page.
Cross-browser tested.
Expected behaviour: Page renders and works in Chrome, Firefox, Safari, Edge; no console errors or layout breaks.
Mobile responsive verified.
Expected behaviour: Layout adapts; no horizontal scroll; CTAs and text readable on 320px+ width.
1.2 Signup Flow
(Product + Dev + QA)
Pending
Only essential fields collected.
Expected behaviour: Signup form has minimal fields (e.g. email, password, name); no optional fields blocking completion.
Email verification works.
Expected behaviour: Verification email sent; link or code works; user can complete verification and reach dashboard.
No duplicate account creation.
Expected behaviour: Same email cannot create two accounts; clear message if email already exists.
Signup completes under 60 seconds.
Expected behaviour: From start to dashboard, flow completes in under 60 seconds for a typical user.
Redirect to dashboard successful.
Expected behaviour: After signup or signin, user lands on dashboard with app list or onboarding.
Error handling user-friendly.
Expected behaviour: Validation and API errors show clear, actionable messages; no raw codes or stack traces.
Phase 2 – App Creation Flow Stability
Owner: Product | Responsible: Dev + QA + UX + Architect
Pending
2.1 Create App Entry UX
(UX + Dev)
Pending
Create button visible above fold.
Expected behaviour: Primary "Create app" or equivalent CTA visible without scrolling on standard viewport.
Single primary CTA.
Expected behaviour: One clear primary action for creating an app; no competing CTAs in same context.
Correct redirect to creation page.
Expected behaviour: Clicking create leads to app creation form or wizard; URL and state correct.
Mobile responsive verified.
Expected behaviour: Create flow usable on mobile; form and buttons accessible and readable.
Cross-browser tested.
Expected behaviour: Create flow works in Chrome, Firefox, Safari, Edge; no layout or submit failures.
2.2 Naming & Validation Logic
(Dev + QA)
Pending
App name mandatory.
Expected behaviour: Submit disabled or validation error until app name provided; message clear.
Duplicate prevention working.
Expected behaviour: Duplicate app name per user/tenant rejected with clear message; no silent overwrite.
Special characters validated.
Expected behaviour: Invalid characters rejected or sanitized; message explains allowed format.
Length constraints enforced.
Expected behaviour: Min/max length enforced; error message when exceeded.
SQL/Injection safe.
Expected behaviour: Input sanitized; no SQL/NoSQL injection possible; safe storage and display.
Edge cases tested.
Expected behaviour: Empty, whitespace-only, very long, and unicode names handled; no crash or data corruption.
2.3 Data & Tenant Integrity
(Backend + QA)
Pending
Correct user mapping.
Expected behaviour: New app is associated with the signed-in user; visible only in their app list.
Tenant isolation enforced.
Expected behaviour: Apps and data scoped by tenant; API and DB rules prevent cross-tenant access.
No cross-account visibility.
Expected behaviour: User A never sees User B's apps or data in list or API responses.
Security rules verified.
Expected behaviour: Backend and Firestore/DB rules allow only owner/tenant access; automated test or manual verification done.
API authentication validated.
Expected behaviour: Create-app API requires valid auth; 401/403 for missing or wrong token.
Phase 3 – Page Builder Stability & Accuracy
Owner: Product | Responsible: Dev + UX + QA + Architect
Pending
3.1 Layout Engine Working
(Dev + UX)
Pending
Single column layout renders correctly.
Expected behaviour: One-column layout displays as designed; no overflow or overlap.
Multi-column grid works.
Expected behaviour: Grid layouts (2–3 columns) render with correct proportions and gap.
Nested layouts supported.
Expected behaviour: Layouts inside layouts render correctly; nesting depth supported as designed.
Slot-based rendering accurate.
Expected behaviour: Components render in correct slots; slotIds match; no wrong placement.
Layout responsive on mobile.
Expected behaviour: Layouts stack or adapt on small viewport; no horizontal scroll.
No component overlap issues.
Expected behaviour: Components do not overlap; z-index and flow correct.
3.2 Component Drag & Drop
(Dev + QA)
Pending
Drag from library works.
Expected behaviour: User can drag component from palette; cursor and preview indicate drag state.
Drop into correct slot.
Expected behaviour: Drop target highlights; component lands in correct slot; tree updated.
Reordering works.
Expected behaviour: Dragging existing component to new position reorders; no duplicate; state persisted.
Nested component drag works.
Expected behaviour: Components can be dragged into nested slots; parent-child relationship correct.
No duplication on fast drag.
Expected behaviour: Rapid drag-and-drop creates only one instance; no double insert.
Drag tested on slow network.
Expected behaviour: On throttled network, drag still completes or shows loading; no hang or corrupt state.
3.3 Component Property Panel
(Dev + UX + QA)
Pending
Property changes reflect instantly.
Expected behaviour: Editing a property in panel updates preview immediately; no delay or manual refresh.
No state loss on refresh.
Expected behaviour: After F5 or navigating away and back, builder state restored from save; no lost edits (or unsaved prompt).
Validation rules configurable.
Expected behaviour: User can add/edit validation rules for form components; rules persist and run at runtime.
Action bindings configurable.
Expected behaviour: User can bind actions (e.g. navigate, submit) to events; bindings persist and execute correctly.
Nested component editing stable.
Expected behaviour: Selecting nested component shows correct props; edits apply to that component only.
Edge case values tested.
Expected behaviour: Empty, very long, special chars in props handled; no crash or corrupt save.
3.4 Data Persistence & JSON Integrity
(Backend + QA + Architect)
Pending
Page JSON saved correctly.
Expected behaviour: Save writes valid JSON to backend; structure matches schema; reload shows same content.
No corrupted schema.
Expected behaviour: Saved JSON is valid; no truncated or malformed data; version compatible.
Version history maintained.
Expected behaviour: Previous versions restorable; history list or rollback available as designed.
Multi-user isolation verified.
Expected behaviour: User A's edits do not overwrite or leak into User B's page; last-write or merge policy clear.
Manual JSON tampering safe.
Expected behaviour: Invalid JSON in store either rejected or repaired; no runtime crash from bad data.
3.5 Preview vs Runtime Accuracy
(QA + Founder)
Pending
Live preview matches runtime output.
Expected behaviour: What user sees in builder preview matches published/live page for same JSON.
Slot rendering consistent.
Expected behaviour: Slots render same in preview and runtime; no missing or extra components.
No missing nested components.
Expected behaviour: Nested component tree fully rendered in preview and runtime.
No slotId null issues.
Expected behaviour: No null or undefined slotId in tree; no crash or blank slot.
Tested across multiple layouts.
Expected behaviour: Single-column, multi-column, and nested layouts all match preview to runtime.
3.6 Page Builder Performance
(Dev + QA)
Pending
Builder loads under 3 seconds.
Expected behaviour: Page builder screen interactive within 3 seconds on typical connection.
No memory leaks.
Expected behaviour: Long editing session does not grow memory unbounded; no need to refresh to recover.
Large page with 50+ components tested.
Expected behaviour: Page with 50+ components loads and scrolls smoothly; edit and save work.
Smooth scroll performance.
Expected behaviour: Scrolling in canvas and panels is smooth; no jank or freeze.
Phase 4 – Component Library Architecture
Owner: Architect | Responsible: Dev + QA + Product
Pending
4.1 Component Schema Standardized
Pending
Unique component ID enforced.
Expected behaviour: Each component instance has unique id; duplicate id prevented or auto-resolved.
Props schema defined.
Expected behaviour: Each component type has defined props schema; panel shows correct fields and types.
Default config defined.
Expected behaviour: New component gets sensible defaults; no required prop missing on add.
Validation schema structured.
Expected behaviour: Validation config follows consistent structure; runtime can interpret and run validations.
Action schema structured.
Expected behaviour: Action bindings follow defined schema; events and targets documented and working.
4.2 Reusability & Isolation
Pending
Component reusable across pages.
Expected behaviour: Same component type can be used on multiple pages; no page-specific lock-in.
No shared mutable state.
Expected behaviour: Component instances do not share state; editing one does not affect another unexpectedly.
No circular dependency issues.
Expected behaviour: Component and config dependencies have no cycle; load order and runtime stable.
Version compatibility maintained.
Expected behaviour: Newer component versions can render older config where backward compatible; migration path exists.
Phase 5 – Runtime Rendering Engine
Owner: Architect | Responsible: Dev + QA
Pending
5.1 JSON → UI Rendering Accuracy
Pending
All component types render correctly.
Expected behaviour: Every component type in the library renders without error for valid config.
Nested components render safely.
Expected behaviour: Deep nesting renders; no stack overflow or missing child.
Slot rendering accurate.
Expected behaviour: Children render in correct slots; order and slotId match schema.
No null/undefined crash.
Expected behaviour: Missing or null props use defaults or fallback; no uncaught exception.
Fallback handling implemented.
Expected behaviour: Unknown component type or invalid config shows placeholder or error component; no white screen.
5.2 Security & Isolation
Pending
XSS safe rendering.
Expected behaviour: User and config content escaped; no script execution from rich text or URLs.
HTML sanitization implemented.
Expected behaviour: Any HTML from config or CMS sanitized; dangerous tags and attributes stripped.
User-level data isolation enforced.
Expected behaviour: Runtime shows only data for current user/tenant; no cross-user leak.
Component injection safe.
Expected behaviour: Malicious or malformed component config cannot execute code or escalate access.
Phase 6 – Publish & Deployment Pipeline
Owner: DevOps | Responsible: Dev + QA + Founder
Pending
6.1 Publish Workflow
Pending
Publish button triggers build.
Expected behaviour: Clicking Publish starts build/deploy pipeline; status visible to user.
Resolve API works correctly.
Expected behaviour: App resolution (subdomain or path) returns correct app and version.
Subdomain routing correct.
Expected behaviour: appid.mudumbai.in (or equivalent) serves the right app; no wrong app or 404.
No manual infra steps required.
Expected behaviour: Publish does not require SSH, manual deploy, or config file edits by user.
Publish tested multiple times.
Expected behaviour: Repeated publish (same or new version) succeeds; no stuck or corrupted state.
6.2 Rollback & Safety
Pending
Previous version retrievable.
Expected behaviour: User or system can load a previous version of the app for rollback or compare.
Rollback tested successfully.
Expected behaviour: Rollback action restores prior version to live; site works after rollback.
Failed publish does not corrupt live app.
Expected behaviour: If publish fails, current live version unchanged; no partial or broken deploy.
Phase 7 – Upkeep & Maintainability
Owner: Founder | Responsible: Architect + Dev + QA
Pending
7.1 Backward Compatibility
Pending
Old apps unaffected by updates.
Expected behaviour: Deploying platform or component updates does not break existing published apps.
Component versioning strategy defined.
Expected behaviour: Documented or implemented strategy for component schema versions and compatibility.
Schema migration handled.
Expected behaviour: Old page JSON can be migrated to new schema where needed; automated or documented process.
7.2 Monitoring & Logging
Pending
Error logs accessible.
Expected behaviour: Team can access application and deploy logs for debugging; retention and access defined.
Critical alerts configured.
Expected behaviour: Critical failures (e.g. service down, publish failure) trigger alert to on-call or team.
Publish failure alerts configured.
Expected behaviour: Publish/build failures generate notification; no silent failure.
Phase 8 – Landing Page & First-Time Visitor Experience
Owner: Product | Responsible: UX + QA | Perspective: First-time visitor, Non-technical user
Pending
8.1 Landing Load, CTA & Scroll
(UX + QA)
Pending
Landing page loads within 2 seconds; primary CTA visible.
Expected behaviour: No console errors, mobile responsive, single clear CTA. Must NOT: blank screen, multiple CTAs, JS errors. User outcome: Value prop and one clear action.
Scroll-to-section does not show adjacent sections peeking; target section fully in view.
Expected behaviour: scroll-margin/offset applied. Must NOT: wrong section visible. User outcome: Smooth predictable scroll.
All sections (hero, features, pricing, FAQ, contact) visible without horizontal scroll.
Expected behaviour: Responsive layout. Must NOT: overflow-x, overlapping text. User outcome: Complete landing experience.
Double-click on primary CTA does not submit twice or open multiple tabs.
Expected behaviour: Single navigation. Must NOT: duplicate signup or redirect. User outcome: One clean transition.
8.2 Signup – Email, Google, OTP
(Dev + QA)
Pending
Email signup: essential fields only; verification email sent; no duplicate account for same email.
Expected behaviour: Clear errors, under 60s. Must NOT: duplicate accounts, silent failure. User outcome: Account created or clear message.
Google sign-in: OAuth flow returns correct user; no duplicate when same email used for Google and email.
Expected behaviour: Single account per email. Must NOT: two accounts, lost session. User outcome: Signed in, redirect to dashboard.
OTP flow: OTP sent, validated, expiry with clear message; resend available.
Expected behaviour: Resend, expiry message. Must NOT: infinite retries, no expiry message. User outcome: Verified or clear next step.
Token expiry during signup shows re-auth or session expired message; no crash.
Expected behaviour: Graceful message, redirect to signin. Must NOT: White screen, undefined error. User outcome: Clear recovery path.
Phase 9 – Dashboard Experience & Navigation
Owner: Product | Responsible: Dev + QA | Perspective: Admin, Paid subscriber
Pending
9.1 Dashboard Load & Data
(UX + QA)
Pending
Dashboard shows only user's apps; no other tenant's apps.
Expected behaviour: Correct list, role-based menu. Must NOT: Cross-tenant data, wrong links. User outcome: My apps and nav only.
Back button from inner page returns to previous view without losing state where expected.
Expected behaviour: Sensible history. Must NOT: Exit to login without warning. User outcome: Predictable navigation.
Refresh on dashboard preserves list; session restored; no logout without reason.
Expected behaviour: Re-auth only if session expired. Must NOT: Unnecessary logout. User outcome: Reload keeps user on dashboard.
Session expiry shows clear message and redirect to signin; no silent failure or corrupt UI.
Expected behaviour: "Session expired, please sign in again". Must NOT: 401 with blank screen. User outcome: Re-login and continue.
9.2 Create App – Validation & Edge Cases
(Dev + QA)
Pending
App name mandatory; duplicate name rejected with clear message; special chars/length validated.
Expected behaviour: Inline or toast error. Must NOT: SQL/script injection, silent fail. User outcome: Valid name or clear error.
Create App submission idempotent on double-click or slow network; only one app created.
Expected behaviour: Single create, loading state. Must NOT: Two apps, duplicate API calls. User outcome: One new app in list.
Network interruption during create shows retry or error; form data preserved where possible.
Expected behaviour: Retry or save draft. Must NOT: Lost form, no feedback. User outcome: Can retry or recover.
Phase 10 – Page Builder, Component Config & Live Preview
Owner: Product | Responsible: Dev + UX + QA | Perspective: Non-technical user, Admin
Pending
10.1 Drag, Drop & Reorder
(UX + QA)
Pending
Drag from library into slot works; drop target clear; no duplicate on fast drag.
Expected behaviour: Single drop, visual feedback. Must NOT: Duplicate nodes, lost drop. User outcome: Component in correct slot.
Reorder and nested drag work; no overlap or slotId null.
Expected behaviour: Valid tree, persisted. Must NOT: Corrupt JSON, missing slotId. User outcome: Layout matches intent.
Drag tested on slow network; no hang or duplicate components.
Expected behaviour: Loading state, single outcome. Must NOT: Multiple copies. User outcome: Reliable drag on poor network.
10.2 Property Panel & Version Mismatch
(Dev + QA)
Pending
Property changes reflect in live preview instantly; no state loss on refresh.
Expected behaviour: WYSIWYG. Must NOT: Stale preview, crash on invalid value. User outcome: Edit and see result.
Component version mismatch (old schema) handled with migration or clear error; no silent corruption.
Expected behaviour: Upgrade path or message. Must NOT: Broken page, lost config. User outcome: Safe upgrade or clear message.
10.3 Live Preview & JSON Integrity
(Dev + QA)
Pending
Live preview matches runtime; slot rendering consistent; no missing nested components.
Expected behaviour: Pixel/behavior match. Must NOT: Extra/missing components. User outcome: WYSIWYG.
JSON corruption (manual edit) does not crash builder or runtime; fallback or validation error shown.
Expected behaviour: Graceful error, recoverable. Must NOT: White screen, data loss. User outcome: Error message and fix path.
Invalid AI-generated JSON has fallback; no crash.
Expected behaviour: Last valid or "try again". Must NOT: Apply broken JSON. User outcome: Safe default or retry.
Phase 11 – Publish, Deployment & Domain/Subdomain
Owner: DevOps + Product | Responsible: Dev + QA | Perspective: Admin, Platform owner
Pending
11.1 Publish & Retry
(DevOps + QA)
Pending
Publish button triggers build; resolve API and subdomain routing correct; no manual infra for standard flow.
Expected behaviour: One-click publish. Must NOT: Partial deploy, broken live. User outcome: Live site updated.
Publish retry mechanism exists; failed publish does not corrupt live app; previous version remains until success.
Expected behaviour: Rollback or hold. Must NOT: Broken live. User outcome: Safe retry.
Deployment failure shows clear message and fallback; logs available.
Expected behaviour: Error message, support path. Must NOT: Silent fail, no logs. User outcome: Know why and what to do.
DNS propagation delay explained or handled (e.g. "may take up to 48h"); custom domain does not assume immediate resolution.
Expected behaviour: Message or status. Must NOT: User thinks site broken. User outcome: Set expectation.
11.2 Domain / Subdomain
(DevOps + QA)
Pending
Subdomain (e.g. app.mudumbai.in) works for published app; SSL valid.
Expected behaviour: HTTPS, correct app. Must NOT: Wrong app, mixed content. User outcome: Visit subdomain, see correct app.
Custom domain (if offered) configurable; DNS instructions clear; no broken certificate.
Expected behaviour: Step-by-step or doc. Must NOT: Vague or insecure. User outcome: Custom domain works or clear steps.
Phase 12 – Security, Billing & User Management
Owner: Product + Security | Responsible: Dev + QA | Perspective: Admin, Platform owner
Pending
12.1 Security & RBAC
(Security + QA)
Pending
Role-based access enforced; editor cannot see admin-only screens; API rejects unauthorized.
Expected behaviour: 403 or redirect. Must NOT: Data leak, privilege escalation. User outcome: See only allowed actions.
Data isolation: tenant A never sees tenant B data in API or UI.
Expected behaviour: Strict tenant filter. Must NOT: Cross-tenant list/detail. User outcome: Only own data.
Rate limiting / abuse protection; excessive requests get 429 or backoff message.
Expected behaviour: Graceful degradation. Must NOT: DoS or silent block. User outcome: "Too many requests" or retry later.
12.2 Billing & Subscription
(Product + QA)
Pending
Billing page shows current plan, usage, next charge; no other tenant's data.
Expected behaviour: Correct amounts, dates. Must NOT: Wrong plan, wrong user. User outcome: Understand subscription.
Billing retry logic on failed charge: retry policy and user notification (email/in-app) verified.
Expected behaviour: Retry then notify. Must NOT: Silent cancel, no notice. User outcome: Know about failure and how to fix.
Subscription downgrade: access adjusted at period end; no immediate revoke before end.
Expected behaviour: Pro-rata or end-of-period. Must NOT: Instant feature loss without notice. User outcome: Fair transition.
12.3 User Management & Audit
(Admin + QA)
Pending
Admin can invite/remove users; roles apply; removed user loses access on next request.
Expected behaviour: Role change or revoke. Must NOT: Stale access. User outcome: Team access matches intent.
Audit logging completeness: login, publish, billing, user change logged with who/when/what.
Expected behaviour: Queryable logs. Must NOT: Missing critical events. User outcome: Platform owner can audit.
Phase 13 – Templates, AI JSON, Code Gen & CI/CD
Owner: Product + DevOps | Responsible: Dev + QA | Perspective: Admin, Developer
Pending
13.1 Template Usage
(UX + QA)
Pending
Template selection applies correct starting JSON; no corrupted or partial template.
Expected behaviour: Full page structure. Must NOT: Missing components, wrong schema. User outcome: Start from template and edit.
Template list loads; no cross-tenant template leak.
Expected behaviour: Relevant templates only. Must NOT: Wrong tenant templates. User outcome: Choose template and go.
13.2 AI JSON & Code Gen
(Dev + QA)
Pending
AI JSON produces valid schema; invalid AI response has fallback (last valid or "try again").
Expected behaviour: Safe apply or reject. Must NOT: Corrupt page JSON. User outcome: Applied or clear error.
Code gen & GitHub push: export succeeds; correct repo/branch; GitHub API rate limit handled with message or backoff.
Expected behaviour: Clear success or rate-limit message. Must NOT: Silent fail, wrong repo. User outcome: Code in repo or clear reason.
13.3 CI/CD Pipeline
(DevOps + QA)
Pending
CI/CD runs on push; build/deploy complete or fail with visible status.
Expected behaviour: Green/red, logs. Must NOT: Silent skip, wrong env. User outcome: Deploy traceable to commit.
Pipeline failure does not leave production broken; rollback or hold previous version.
Expected behaviour: Safe state. Must NOT: Half-deployed. User outcome: Production stable.
Phase 14 – Analytics, Audit, Mobile & Error Handling
Owner: Product | Responsible: Dev + QA + UX
Pending
14.1 Analytics & Logging
(Product + QA)
Pending
Analytics dashboard shows correct metrics for owned apps only; no cross-tenant data.
Expected behaviour: Filters by tenant/app. Must NOT: Other users' stats. User outcome: See own usage.
Analytics opt-in/out (if applicable) respected; no tracking when opted out.
Expected behaviour: Configurable, documented. Must NOT: Track when disabled. User outcome: Privacy respected.
14.2 Audit Trail & Production Safety
(Security + QA)
Pending
Audit trail includes key actions (publish, user change, billing, settings); who/when/what queryable.
Expected behaviour: Complete for compliance. Must NOT: Gaps for critical actions. User outcome: Audit possible.
Destructive actions (e.g. delete app) require confirmation; no accidental wipe.
Expected behaviour: Confirm dialog. Must NOT: One-click delete. User outcome: No accidental loss.
14.3 Mobile & Error Handling
(UX + QA)
Pending
Key flows (landing, signup, dashboard, create app, builder, publish) usable on mobile; no horizontal scroll, tap targets adequate.
Expected behaviour: Responsive, touch-friendly. Must NOT: Broken layout, tiny buttons. User outcome: Use on phone.
API/network errors show user-friendly message and retry or support path; no raw stack trace or "undefined".
Expected behaviour: Message + action. Must NOT: White screen, dev errors. User outcome: Know what went wrong.
Storage quota limits (if applicable) surface clear message when exceeded; no silent failure.
Expected behaviour: "Storage full" or upgrade prompt. Must NOT: Save fails without reason. User outcome: Free space or upgrade.
Phase 15 – Edge Cases, Performance & Failure Recovery
Owner: Architect + DevOps | Responsible: Dev + QA
Pending
15.1 Edge Case & Negative Testing
(QA)
Pending
Invalid URLs or deleted resources return 404 or friendly "not found"; no crash.
Expected behaviour: 404 page or message. Must NOT: 500 or blank. User outcome: Clear "not found".
Expired or invalid link (magic link, password reset) shows clear message and option to request again.
Expected behaviour: Message + CTA. Must NOT: Generic error. User outcome: Request new link.
XSS/injection in text fields sanitized; script tags not executed.
Expected behaviour: Escaped/sanitized output. Must NOT: Script execution. User outcome: Safe content.
15.2 Performance & Failure Recovery
(Dev + QA)
Pending
Builder and dashboard load within acceptable time (e.g. under 3s); large page (50+ components) does not freeze.
Expected behaviour: No memory leak, smooth scroll. Must NOT: Timeout or hang. User outcome: Usable under load.
After network restore, user can retry failed action; session restored where possible.
Expected behaviour: Retry button or auto-retry. Must NOT: Stuck state. User outcome: Recover without full reload.
Rollback after failed publish restores previous version; no corrupted live state.
Expected behaviour: One-click rollback. Must NOT: Broken production. User outcome: Back to last good version.
Phase 16 – Minor & Critical Production Readiness
Owner: QA + DevOps | Responsible: Dev + QA | All minor test cases
Pending
16.1 Double-Click, Back, Refresh, Session
(QA)
Pending
Double-click prevention on all primary actions (signup, create app, publish, save, submit).
Expected behaviour: Single submission, loading state disables button. Must NOT: Duplicate records or navigation. User outcome: One action per intent.
Back button behaviour: browser back returns to previous app view where expected; no unexpected logout or data loss.
Expected behaviour: Sensible history. Must NOT: Lose unsaved warning. User outcome: Predictable back.
Refresh persistence: after F5, user remains logged in; dashboard/app list restored; unsaved builder state handled (prompt or auto-save).
Expected behaviour: Session restored. Must NOT: Silent logout. User outcome: Reload preserves session.
Session expiry handling: idle timeout or token expiry shows clear message; redirect to signin; no corrupt UI.
Expected behaviour: Message + redirect. Must NOT: 401 with blank page. User outcome: Re-login and continue.
16.2 Network, Token & Interruptions
(Dev + QA)
Pending
Network interruption during request: user sees error and retry option; no infinite spinner.
Expected behaviour: Timeout, retry or "Check connection". Must NOT: Hang forever. User outcome: Know to retry or reconnect.
Token expiry: refresh token flow works or clear "Session expired" and redirect to signin.
Expected behaviour: Re-auth or redirect. Must NOT: Silent fail, raw 401. User outcome: Re-login path clear.
16.3 Builder & Data Edge Cases
(QA)
Pending
Component version mismatch: old page JSON with deprecated component version opens with migration or clear error; no silent corruption.
Expected behaviour: Upgrade or message. Must NOT: Broken page. User outcome: Safe upgrade path.
JSON corruption handling: malformed or truncated page JSON does not crash builder or runtime; validation error or fallback.
Expected behaviour: Error message, recover from history. Must NOT: White screen. User outcome: Recover or restore.
Invalid AI response fallback: if AI returns invalid JSON or empty, apply last valid or show "Try again"; never apply broken structure.
Expected behaviour: Safe default. Must NOT: Corrupt page. User outcome: Retry or revert.
16.4 External Services & Deployment
(DevOps + QA)
Pending
GitHub API rate limit: when hit, show clear message and backoff or "Try later"; no silent fail.
Expected behaviour: User-facing message. Must NOT: Push fails with no explanation. User outcome: Retry later.
Deployment failure fallback: build or deploy failure does not replace live with broken version; previous version stays live.
Expected behaviour: Hold, rollback. Must NOT: Broken production. User outcome: Site stays up.
Publish retry mechanism: user can retry after failure without re-entering data; clear success/failure state.
Expected behaviour: Retry button, state clear. Must NOT: Stuck "Publishing". User outcome: Retry or cancel.
DNS propagation delay handling: custom domain flow mentions delay (e.g. 24–48h); status or health check available.
Expected behaviour: Set expectation. Must NOT: "Site not working" with no explanation. User outcome: Wait or check status.
16.5 Compliance & Limits
(Product + QA)
Pending
Analytics opt-in/out behaviour: if user opts out, no tracking; setting persisted and documented.
Expected behaviour: No events when out. Must NOT: Track after opt-out. User outcome: Privacy respected.
Audit logging completeness: all sensitive actions (auth, publish, billing, user mgmt, settings) logged with identity and timestamp.
Expected behaviour: No gaps. Must NOT: Missing critical events. User outcome: Full audit trail.
Role-based access isolation: each role sees only allowed screens and data; API enforces same.
Expected behaviour: 403 for forbidden. Must NOT: UI hide but API allow. User outcome: No privilege escalation.
Storage quota limits: when limit reached, clear message and upgrade or free space option; no silent save failure.
Expected behaviour: "Quota exceeded" or similar. Must NOT: Save fails with generic error. User outcome: Can act on limit.
Rate limiting abuse protection: repeated rapid requests throttled with 429 or message; no DoS from single user.
Expected behaviour: Backoff or "Too many requests". Must NOT: Silent block with no message. User outcome: Slow down or retry later.
Phase 17 – User-Action UAT (On Click / On Submit – Expected Behaviour)
Owner: QA + Product | Perspective: End user | Each item = action → expected outcome
Pending
17.1 Landing / Homepage – Buttons & Links
(User on /)
Pending
On click
Get Started
(hero): user is navigated to Sign In page (/signin).
Expected behaviour: Single navigation, no new tab; URL is /signin; form visible.
On click
Book Setup Call
(Quick Help): user is navigated to Sign In page.
Expected behaviour: Same as Get Started; intent is to sign in to book.
On click
Explore Academy
: YouTube Academy opens in new tab; same tab stays on MUDUMBAI.
Expected behaviour: target="_blank"; no redirect of current page.
On click
Get Started
or
Sign In
in header: user goes to Sign In page (or configured UAT signin URL).
Expected behaviour: Consistent with hero Get Started.
On click nav links (Home, Features, Pricing, etc.): page scrolls to section; section is in view and not partially hidden.
Expected behaviour: scroll-margin/offset applied; no adjacent section peeking.
17.2 Sign In Page – Form & Validations
(User on /signin)
Pending
On click
Sign in
with empty email/password: form does not submit or shows validation/error.
Expected behaviour: Either inline validation or error message (e.g. "User not found" / "Please enter email"); no silent fail.
On click
Sign in
with valid credentials: user is signed in and redirected to Dashboard (/dashboard).
Expected behaviour: No error message; dashboard shows app list or empty state.
On click
Sign in
with wrong password or unregistered email: error message shown (e.g. "User not found" / "Signin failed"); user stays on Sign In page.
Expected behaviour: Clear, user-friendly message; form preserved.
On click
Google
sign-in: OAuth flow opens; on success user lands on Dashboard.
Expected behaviour: Popup or redirect; on success redirect to /dashboard; no duplicate account.
On click
Create an account
link: navigate to Sign Up page (/signup).
Expected behaviour: Single navigation; signup form visible.
On click
Forgot password
(if present): navigate to Forgot Password page (/forgot-password).
Expected behaviour: Form to enter email visible.
17.3 Sign Up Page – Form & Validations
(User on /signup)
Pending
On click
Create account
with empty first name or email: error shown (e.g. "Please enter your first name" / "Please enter your email").
Expected behaviour: Submit blocked or error message; user stays on form.
On click
Create account
with password < 8 chars: error shown (e.g. "Password must be at least 8 characters").
Expected behaviour: Validation before API call; clear message.
On click
Create account
with password ≠ confirm password: error shown (e.g. "Passwords do not match").
Expected behaviour: No submit; message clear.
On click
Create account
with all valid fields: account created; user redirected to Dashboard; verification email sent message if applicable.
Expected behaviour: No error; redirect to /dashboard; optional success message.
On click
Google
sign-up: OAuth flow; on success redirect to Dashboard.
Expected behaviour: Single account; no duplicate for same email.
On click
Sign in
link: navigate to Sign In page.
Expected behaviour: URL /signin; signin form visible.
17.4 Forgot Password Page
(User on /forgot-password)
Pending
On click
Send Reset Link
with empty email: error shown (e.g. "Please enter your email address").
Expected behaviour: No API call; inline or toast error.
On click
Send Reset Link
with valid email: success message (e.g. "Check your inbox"); reset email sent.
Expected behaviour: Sent state shown; note about spam folder if applicable.
On click
Back to Sign in
/
Sign in
link: navigate to Sign In page.
Expected behaviour: URL /signin.
17.5 Dashboard – Actions & Navigation
(User on /dashboard)
Pending
On click
Create App
/
Create new app
: navigate to Create App page (/create-app).
Expected behaviour: Create app form with App Name and Description visible.
On click an
app card/tile
: navigate to Page Builder or app-specific screen (e.g. page-builder?app=… or setup-wizard).
Expected behaviour: Correct app context; no wrong app data.
On click sidebar/menu items (Validations, Assets, Data Management, Integrations, Analytics, Billing, Settings, Manage Users): navigate to corresponding route; page loads without error.
Expected behaviour: Correct page and data for current user.
On click
Logout
: user signed out; redirected to Goodbye or Sign In.
Expected behaviour: Session cleared; no access to private routes until sign in again.
17.6 Create App Page – Form & Submit
(User on /create-app)
Pending
On click
Let's Start
with empty App Name or Description: error/alert (e.g. "Please fill App Name & Description"); no API call.
Expected behaviour: User stays on form; fields highlighted or message shown.
On click
Let's Start
with valid App Name and Description: backend called; on success redirect to Setup Wizard (e.g. /setup-wizard/AppName/welcome).
Expected behaviour: Loading state during request; success message optional; single app created.
On click
Let's Start
when backend unreachable: error shown (e.g. "Backend API not reachable"); user stays on Create App page.
Expected behaviour: No redirect; clear message; can retry when backend is up.
On select app type (Static Website / Web Application / Enterprise): selection updates; selection persists when submitting.
Expected behaviour: Visual state reflects selection; submitted app type correct.
17.7 Setup Wizard – Steps & Forms
(User in /setup-wizard/:appName/…)
Pending
On click
Next
/ step navigation with required fields empty: validation prevents advance or shows error.
Expected behaviour: User remains on step or sees which fields are required.
On click
Next
with valid data: move to next step; progress saved where applicable.
Expected behaviour: URL and content update to next step; no data loss.
On click
Back
: previous step shown; data preserved.
Expected behaviour: Same behaviour as Next in reverse.
On click
Complete
/
Finish
on last step: wizard completes; redirect to dashboard or page builder.
Expected behaviour: App marked complete or ready; user can open app.
17.8 Page Builder – Key Actions
(User on /page-builder)
Pending
On click
Save
: page JSON saved; success feedback (toast or message).
Expected behaviour: No error when save succeeds; refresh or reload shows same content.
On click
Publish
: publish workflow starts; user sees status or success/failure.
Expected behaviour: Live app updated on success; on failure clear message and no corrupt live.
On
drag
component from library to canvas: component appears in drop target; one instance only.
Expected behaviour: Preview and tree update; no duplicate on fast drag.
On
select
component and edit property in panel: preview updates immediately.
Expected behaviour: WYSIWYG; no stale preview.
On click
Logout
or navigate away with unsaved changes: prompt or auto-save so user does not lose work unexpectedly.
Expected behaviour: Either "Unsaved changes" prompt or auto-save; no silent loss.
17.9 Validations, Data Management, Integrations, Other Pages
(User on /validations, /data-management, etc.)
Pending
On
Validations
page: add/edit/delete validation rules; save persists; form validations work (required fields, formula).
Expected behaviour: Rules save and apply at runtime; no crash on invalid formula.
On
Data Management
page: list loads for selected app; create/edit/delete record works; validations apply on submit.
Expected behaviour: CRUD operations succeed; errors shown for invalid data.
On
Integrations
page: configure integration; save succeeds or clear error.
Expected behaviour: Configuration saved; connection test (if any) reflects real status.
On
Assets
page: upload/list/delete assets; picker shows correct assets in builder.
Expected behaviour: Upload completes; assets scoped to app/user; no cross-tenant leak.
On
Analytics
,
Billing
,
Settings
,
Manage Users
: page loads; primary buttons (e.g. upgrade, save settings, invite user) perform expected action or show validation.
Expected behaviour: Data correct for current user; actions succeed or show clear error.
17.10 Goodbye & Private Route
(User flow)
Pending
After logout: user lands on Goodbye page then redirect to Sign In (or direct to Sign In).
Expected behaviour: Message like "You have been signed out"; redirect within few seconds.
When not signed in, opening /dashboard or any private route: redirect to Sign In.
Expected behaviour: No flash of private content; URL ends on /signin.
When signed in, opening / or /signin: redirect to dashboard or show landing with option to go to dashboard.
Expected behaviour: Authenticated user not stuck on signin form.
Phase 18 – Action Management, Validations Config, Session/State, Integrations & Wizard Gaps
Owner: QA + Product | Failure scenarios, validations while configuring, session/state, missing flows
Pending
18.1 Action Management – Failure Possibilities & Validations
(Actions page, Action Config)
Pending
No app in URL
(/actions without ?app=): page shows "No App Selected" and "Go to Dashboard"; no crash.
Expected behaviour: Clear empty state; no API call for actions.
Save Action
with empty action name: validation blocks save; alert "Please enter an action name".
Expected behaviour: No API call; user stays on form.
Save Action
without selecting Action Type: validation blocks save; alert "Please select an Action Type".
Expected behaviour: No API call; dropdown or message visible.
Open Page
action – External selected but URL empty: validation blocks save; alert "Please enter a website URL".
Expected behaviour: Save blocked until URL provided.
Open Page
action – Internal selected but no page chosen: validation blocks save; alert "Please select a page".
Expected behaviour: Save blocked until page selected from dropdown.
Save Action
when backend/API fails: user sees error (e.g. "Failed to save action"); form data preserved; no silent fail.
Expected behaviour: Alert or toast; user can retry.
Load actions list
when API fails: list shows error or empty state; no crash; retry possible.
Expected behaviour: Loading ends; message or empty state; no white screen.
Delete action
when API fails: error shown; list not corrupted; user can retry.
Expected behaviour: Alert "Failed to delete action"; list unchanged or refreshed.
Edit existing action
and save as new version: confirm dialog; new version saved; list refreshes.
Expected behaviour: Version incremented; no overwrite without confirm.
Action-type-specific required fields (e.g. phone for makeCall, sectionId for scrollToSection): invalid or empty required config blocked or validated before save.
Expected behaviour: Per-type validation; clear message.
18.2 Validations Configuration – Failure Possibilities & Validations
(Validations page, formula, rules)
Pending
Save validation rule
with invalid or empty formula: validation blocks save or shows error; no corrupt rule persisted.
Expected behaviour: Formula syntax or required-field check; clear error message.
Formula references
non-existent field or broken reference: error shown at save or at runtime; no crash.
Expected behaviour: Validation or runtime message; fallback or safe eval.
Validations list load
when API/service fails: page shows error or empty state; no crash.
Expected behaviour: Loading ends; user can retry or go back.
Business rules / formula builder
– invalid expression: error highlighted or message shown; save disabled until valid.
Expected behaviour: No silent accept of invalid formula.
Clear caches
(validation cache, registry, computed engine): confirm dialog; caches clear; stats update; no crash.
Expected behaviour: Destructive action confirmed; UI reflects cleared state.
Validation rule applied to component at runtime with missing data source: graceful fallback or error message; no uncaught exception.
Expected behaviour: Runtime validation degrades safely.
18.3 Session Management & State Management
(Auth store, App store, Selected app, localStorage)
Pending
Auth persistence
: after refresh, user remains logged in (user read from localStorage).
Expected behaviour: useAuthStore hydrates from klmn_auth_user_v1; PrivateRoute allows access.
Logout
: user and localStorage key cleared; redirect to Goodbye or Sign In.
Expected behaviour: No stale user in memory or storage; private routes redirect.
Selected app
: selectedApp persisted in localStorage (klmn_selected_app_v1); refresh restores selection.
Expected behaviour: Integrations/Actions etc. show correct app when opened with ?app= or from context.
App store (create-app)
: appName, appDesc, currentStep not persisted; refresh on create-app clears form.
Expected behaviour: No stale app name when visiting create-app again; step loader resets.
Multi-tab
: login in one tab; other tab sees auth (if shared storage) or after refresh.
Expected behaviour: Consistent behaviour; no infinite redirect loop.
Token/session expiry
: when backend or Firebase rejects auth, user shown "Session expired" and redirected to Sign In.
Expected behaviour: Clear message; no 401 with blank screen.
localStorage full or disabled
: app degrades gracefully; no crash on setItem failure.
Expected behaviour: Auth may not persist; user can still use app in same session.
18.4 Integrations Page – Gaps & Missing
(IntegrationPage, wizard integrations)
Pending
App context
: Integrations page shows app name from URL (?app=) or selectedApp store; when missing, message or redirect.
Expected behaviour: "Integrations for: AppName" or "Connect external services"; no wrong app.
All integrations currently "Coming Soon"
: no save or test connection yet.
Expected behaviour: When integrations are implemented: config form, Save, Test Connection, validation for required credentials.
Future: Save integration
with invalid or missing credentials: validation blocks save; clear error.
Expected behaviour: Required fields validated; API errors shown.
Future: Test connection
button: success/failure feedback; no crash on network error.
Expected behaviour: Clear "Connected" or "Failed" message.
Accordion expand/collapse and "Coming Soon" messaging: no crash; consistent UX.
Expected behaviour: Expand shows details and Coming Soon note; collapse works.
18.5 Setup Wizard Pages – Gaps & Failure Scenarios
(SetupWizard, steps, navigation)
Pending
Step order by app type
: static vs webapp vs enterprise show correct steps (e.g. Data, Validations, Actions only for webapp/enterprise).
Expected behaviour: Steps array filtered by appType; no wrong step shown.
Back
on first step: button disabled; no navigation.
Expected behaviour: Back disabled on welcome; no negative index.
Continue
without required step data (e.g. Data step, Pages step): validation prevents advance or shows error where implemented.
Expected behaviour: Either validation or explicit "optional" so user can skip.
Skip Step
: moves to next step; progress bar updates; no data loss for completed steps.
Expected behaviour: URL and step label update; optional steps skippable.
Refresh
during wizard: appName in URL and useAppStore set from params; step may reset to current URL.
Expected behaviour: Step derived from URL; no infinite redirect.
Change Type
from wizard: navigates to create-app with edit params; user can change type and return.
Expected behaviour: Navigate to /create-app?edit=AppName¤tType=webapp; no orphan state.
Complete
step: no Continue button; redirect or link to dashboard/page builder.
Expected behaviour: User can exit wizard and open app.
Logout
during wizard (if enabled): session cleared; redirect to Goodbye/Sign In.
Expected behaviour: No half-saved wizard state required; clean logout.
Wizard step that calls API (e.g. Generating, Data): on API failure, error shown; user can retry or go back.
Expected behaviour: No silent fail; retry or Back available.