santhosh-vj/zoho-to-do

Purpose and Entry Points

This is a browser-based “Shadow” task/workflow application with agenda, personal-task, approval, administration, analytics, settings, and workflow-builder surfaces. Primary HTML entry points are:

• shadow/index.html — main application shell.

• shadow/workflow.html — workflow management/builder surface.

• shadow/admin.html — administration dashboard.

• shadow/settings.html — user settings.

• shadow/playground.html — isolated experimentation/demo surface.

Netlify deployment configuration is defined in netlify.toml.

Application Shell and Feature Views

The main client is orchestrated from shadow/app.js, with shared UI styling in shadow/styles.css. Feature-specific views divide the task experience by context:

• shadow/agenda-view.js

• shadow/myday-view.js

• shadow/createdbyme-view.js

Supporting task capabilities include templates, likes, form corrections, and enhancements in shadow/task-templates.js, shadow/task-likes.js, and shadow/task-enhancements.js. This suggests a modular front-end where views consume common task state/API behavior rather than each owning a backend.

Backend and Persistence Boundary

Client/server or persistence integration is centered on:

• shadow/backend.js

• shadow/approval-backend.js

• shadow/shadow-workflow-backend.js

Database and access fixes are separated into patch modules, notably shadow/shadow-db-patch.js and shadow/shadow-user-access.js. The naming indicates the browser application may load incremental compatibility/patch scripts alongside its core backend adapters. Consumers should treat these modules as the boundary between UI state and remote persisted task, approval, workflow, and user-access data.

Identity, Authorization, and Administration

Authentication is explicitly integrated with Supabase through shadow/auth-supabase.js, with UI/session handling in shadow/auth.js and access gating in shadow/shadow-auth-gate.js. Role-based access control is implemented across:

• shadow/rbac.js

• shadow/rbac-ui.js

• shadow/admin-dashboard.js

Administration is exposed through shadow/admin.html and shadow/admin.js. The core control flow is authentication → user-access validation → role evaluation → conditional exposure of administrative, approval, and workflow operations.

Workflow and Approval Pipeline

Workflow authoring, execution, and visualization are distinct stages:

• shadow/workflow-builder.js builds/edit workflows.

• shadow/workflow-engine.js evaluates or runs workflow logic.

• shadow/workflow-ui.js presents workflow interactions.

• shadow/shadow-workflow-backend.js persists or retrieves workflow state.

Approvals form an adjacent workflow path via shadow/approval-ui.js and shadow/approval-backend.js, with targeted rollout/fix scripts in shadow/shadow-approval-patch.js. A deployment helper, shadow/deploy-approval-workflow.sh, indicates approvals/workflow backend infrastructure may require an explicit deployment step separate from static client publishing.

User Preferences, Notifications, and Onboarding

User-facing state and personalization are handled by:

• shadow/settings.js and shadow/settings.html

• shadow/theme.js

• shadow/notification-settings.js

• shadow/notification-bell.js

• shadow/onboarding.js

These modules sit after identity establishment and before normal task/workflow use: authenticated users configure preferences, receive notification UI, and complete onboarding. Analytics and group-oriented functionality are independently surfaced in shadow/analytics-dashboard.js and shadow/group-ui.js, likely consuming the same authenticated backend boundary rather than defining separate application entry points.