DPS System User Manual

The Dashboard is the project-level command centre of the DPS System. It aggregates real-time metrics from all UI Canvases, API Canvases, and backlog tasks into a single page, giving managers and product engineers an instant read on project health.

Aligned with the Canvas-Driven Project Execution Metric model from the CaDPM™ guide, the Dashboard surfaces five execution signals: code delivery progress, time estimates, projected completion date, requirements alignment, and team activity — all derived automatically from live canvas data.

Page Header

Top KPI Cards

Four summary cards run across the top of the page, providing instant project-size context.

Metric Widgets

This widget measures code delivery progress across the entire project by comparing Estimated Code Lines (ECL) against Developed Code Lines (DCL) aggregated from all linked GitHub commits on every UI Canvas.

The Estimated Completion widget provides a project-wide hour-based time tracking view — showing how many hours have been spent and how many remain before the projected completion date.

The Project Completion widget projects when the project will finish based on the current development velocity and remaining estimated hours. It is powered by an AI estimation model and records who ran the last check and when.

The Project Requirement Alignment widget aggregates the BRA (Business Requirements Alignment) scores from every UI Canvas into a project-wide percentage. It answers the question: Does the code being written actually match what was specified in the canvases?

The Snap Shot widget is a distilled three-signal summary of the current project execution state. It condenses the most important delivery indicators into a single glanceable card — ideal for stand-ups or status updates.

The UI Canvas Progress Overview widget shows the delivery status distribution of all canvas screens in the project. It answers: How many screens are done, how many are being worked on, and how many haven't started yet?

The UI Editor is the visual screen-building workspace inside the DPS System. It allows product engineers to drag, drop, and configure UI components onto a canvas to construct interactive screen prototypes. Every component placed here is automatically linked to the Input & Description rows defined in the parent UI Canvas, keeping design and specification always in sync.

The editor is divided into four main zones: the Component Toolbar on the far left, the Canvas Area in the centre, and the CSS Panel on the right. A global toolbar at the top provides project navigation, user context, and the Live Preview action.

Top Application Bar

Left Application Navigation

The collapsible side-nav gives access to all modules within the current project.

The Component Toolbar is the narrow panel on the far left of the canvas area. It presents the complete catalogue of UI primitives available for building a screen prototype. Components are organised in a two-column icon grid — drag any icon onto the canvas to instantiate that element.

Available Component Types

Each icon corresponds to one of the 16 component types from the CaDPM™ specification. The same types are used in the Component Information panel of the UI Canvas (see UI Canvas Section 12).

The Canvas Area is the central workspace where the screen prototype is assembled. Components dragged from the toolbar are placed here on a responsive 12-column grid. The canvas renders a live visual approximation of the final application screen, including real form controls and layout.

Canvas Interactions

Canvas Bottom Bar

The CSS Panel is the right-side styling workspace. It becomes active when a component on the canvas is selected, allowing precise visual customisation at four different levels: the entire canvas, a layout container, an individual component, or the canvas background.

When no component is selected, the panel displays "No component selected" and all inputs are disabled until an element on the canvas is clicked.

TARGET — CSS Scope Selector

CONTEXT — Dimensions

RAW CSS

SELECTION — Attribute Binding

COLORS

Live Preview renders the current canvas as a fully interactive web page in a new browser tab. It strips away all editor UI (toolbar, CSS Panel, navigation) and shows only the prototype — exactly as an end-user would experience it in the final application.

The preview is generated from a unique public URL (e.g., /ui-canvas/preview/{canvas-id}) and can be shared with stakeholders for review and sign-off without requiring a DPS System account.

The Data Flow module generates a live directed-graph visualisation of all navigation paths between UI Canvas screens in the project. It is built automatically — every Form Action (redirect or popup) defined inside a UI Canvas creates an arrow between two canvas nodes. No manual drawing is required; the diagram always reflects the current state of the project's screen navigation structure.

The diagram is read left-to-right: screens that other screens navigate to appear to the right of their source. The selected node (highlighted in blue) is shown in the page header. Circular paths — where screen A eventually redirects back to itself — are flagged with a red loop-detection highlight.

Each UI Canvas in the project is represented as a rectangular canvas node. A node packs several pieces of information into a compact card that immediately communicates both the identity of the screen and its connectivity within the navigation graph.

Node Elements

Example — "Menu Page" Node

In the diagram, Menu Page (color: bc1f60) shows redirect 4 and in 1: it is reached by one screen (Login) and itself redirects to four other screens (Login, Edit User Screen, Users List Screen, Add / Create User Screen).

Arrows in the Data Flow graph represent the navigation actions configured in the Form Action panel of each UI Canvas. Every arrow is labelled with its action type so the navigation intent is immediately readable without opening individual canvases.

The Data Flow module automatically detects circular navigation paths — situations where following a sequence of redirect or popup actions eventually leads back to a canvas that was already visited in the path. When a loop is detected, the repeated canvas node is rendered with a red / pink background and prefixed with "Loop to" to make the cycle visually unmistakable.

The Data Flow toolbar provides controls for navigating and exporting the diagram. It sits directly above the canvas area and adapts to the currently selected canvas node.

Top Toolbar

Bottom Controls

The UI Canvas is the central workspace where each screen of an application is designed, documented, and tracked end-to-end. It connects design intent with development metrics, acceptance criteria, and AI-powered analysis — all in a single view.

The top-level UI Canvas page lists every screen canvas belonging to the selected project. From here you can create new screens, access AI tools, manage GitHub file associations, and drill into individual canvas sections.

Top Bar Controls

Collapsible Sections

Global UI Elements

The Summary section provides a real-time health snapshot of the canvas screen. It surfaces five metrics that together describe how far along development is and how well the implementation aligns with the original business requirements.

The GitHub Files section links source code files from your connected GitHub repositories directly to the canvas. This connection powers the real-time DCL (Developed Code Lines) metric and the BRA (Business Requirements Alignment) score.

Clicking the Action button in the top bar opens a dropdown menu with canvas-level utilities. These actions apply to the entire canvas, not to individual sections.

The UI Canvas AI Assistant is a generative AI tool that drafts content for all four major canvas sections from a single natural-language prompt.

The UI Canvas AI Analyzer inspects the existing canvas content and returns a structured quality report. Unlike the AI Assistant (which creates content), the Analyzer critiques and validates what already exists.

The Description section holds a plain-text functional summary of the canvas screen. It answers: What does this screen do and why does it exist?

The User Acceptance Criteria (UAC) section defines testable conditions that must all be satisfied before this screen is considered done.

Header Summary Badges

Criteria Table Columns

Manage Related Issues Dialog

The UI View section renders the visual representation of the screen — either as a DPS-built UI Prototype or as an externally embedded design (Figma, etc.).

CSS Panel

The External View Link panel manages visual assets — screenshots, Figma embeds, or image URLs. Multiple views can be added; one is the Default View.

Add Embed Code Modal

The Input & Description section is a structured registry of every UI element on the screen with its type, validation rules, and relationships to APIs and form actions.

Table Columns

Row Actions Sidebar

Configures the technical properties of a UI element: its visual type, grid width, and static content.

Provides a structured form for defining validation rules and value constraints for an input element. Generates a standardized description used by the AI Analyzer and Code Builder.

Rules (Checkboxes)

Values (Input Fields)

The Event API Call panel associates an API endpoint with a UI element, documenting the backend integration for a specific user interaction.

The Form Action panel defines what happens after the form completes — typically a navigation redirect to another screen.

The API Canvas is the API endpoint design and documentation workspace inside the DPS System. Each canvas represents one API endpoint (e.g.,insert/user) and holds all information needed to describe, test, and generate code for that endpoint: its description, request headers, request body, operation steps, output schema, and response example.

The canvas is structured as a series of collapsible sections. Each section can be expanded independently by clicking the arrow toggle on the left. Changes are auto-saved; the save icon on the right of each section confirms persistence.

Endpoint Toolbar

Shared API Canvases

Canvas Sections

All six sections are collapsed by default. Each has an expand toggle (▶) on the left and a context action (save icon or + button) on the right.

The Description section holds a plain-text explanation of the endpoint's purpose, behaviour, and security context. It is the primary human-readable documentation for the endpoint and is used by the AI Assistant, AI Analyzer, and the Code Builder when generating implementation code.

Input Fields documents the HTTP headers and query parameters required or accepted by the endpoint. Each entry has a name and a plain-text description. This section is separate from the Request Body — it covers transmission-level inputs (headers, auth tokens) rather than payload content.

Table Columns

Common Input Fields

The Request Body section contains the JSON payload that the client sends to the endpoint. It is an inline code editor with syntax highlighting. The value entered here is used as the default payload when the endpoint is opened in the API Testing module.

The Operation Description section breaks down the backend logic of the endpoint into numbered, sequential processing steps. Each step describes what the server does at that stage — validation, data transformation, database operations, or external service calls.

Steps can carry a coloured operation type badge (e.g., "Insert data") that classifies the server-side action. These badges feed the Code Builder and AI Analyzer to produce correctly typed implementation code.

Output Fields documents the schema of the successful response — every field that the endpoint returns, including nested fields. This table is the machine-readable source of truth for the response structure, used by the UI Canvas Attribute Binding in the CSS Panel and by the Code Builder's DTO generation.

Table Columns

Example — insert/user Response Fields

The Response Body section contains a concrete JSON example of the successful response payload. It complements the Output Fields schema by showing real values in context. This example is displayed in the Live Preview modal and is used as the mock response in API Testing.

Live Preview opens a modal overlay that renders all canvas sections in a clean, read-only format — the same layout used for the public shared view. It allows reviewing the complete API documentation without leaving the editor. Access it from the Action ▾ menu → Live Preview.

The Share dialog generates a public read-only link for the API Canvas. Anyone with the link can view the full canvas documentation without a DPS account. Open it from the Action ▾ menu → Share, or click the dropdown arrow next to the "shared" badge in the endpoint toolbar.

When a visitor opens the public share URL, they see a read-only canvas viewrendered in a plain browser page — no DPS account or login required. A blue banner at the top confirms the read-only state. The layout mirrors the Live Preview modal but is a full standalone page.

The Change History panel is a slide-in sidebar that records every edit made to the API Canvas, including who made the change, when, which field was modified, and what the old and new values were. Open it from Action ▾ → Change History.

API Canvases can be exported as JSON files and re-imported into the same or a different project. Both operations are section-selective — you choose exactly which sections to include, enabling partial transfers without overwriting unrelated data. Access both from Action ▾ → Import or Export.

Import API Canvas

Export API Canvas JSON

Duplicate Canvas creates an exact copy of the current API Canvas — including all six sections — under a new endpoint name within the same project. Use it to create variations of an existing endpoint (e.g., "update/user" from "insert/user") without rewriting shared content from scratch. Access from Action ▾ → Duplicate.

The API Testing module is the live execution environment inside the DPS System. It lets you send HTTP requests directly from the browser, inspect responses, manage environment variables, run load tests, and compare endpoints side by side — all without leaving the platform.

The module is accessible from the left sidebar under API Testing. When opened from an API Canvas via the Test button, the endpoint path, request body, and headers are pre-populated automatically.

Top Toolbar

Request Builder

Tab Panels

Environments let you define named sets of variables (such as base URLs, API keys, or tokens) that are automatically injected into your requests at runtime. Switching environments instantly changes all variable values without editing the URL or body manually — making it effortless to test against development, staging, and production targets.

Open the Environment Management modal by clicking Environments in the top toolbar.

The New Environment dialog allows you to create a named environment and populate it with key-value variable pairs in one step. Variables you add here become immediately available in all request URLs, headers, params, and body fields via the {{key}} syntax.

Clicking Run sends the configured request to the target server and displays the full response in the Response tab. The result includes HTTP status, response time, payload size, and the parsed response body with Body / Headers / Cookies subtabs.

Response Tab Elements

CORS Error

The Request Console Inspector maintains a session-level log of every request sent from the API Testing module. Each entry shows the HTTP method, resolved URL, status code, response time, and payload size. Clicking any row expands a detail panel with the full request and response breakdown.

Open the console by clicking Console (N) in the top toolbar, where N is the count of requests made in the current session.

Request List

Detail Panel — Overview

The Stress Test feature sends repeated requests to an API endpoint to measure its behaviour under load. Use it to identify throughput limits, error rates under concurrency, and response time degradation — directly inside DPS without external tools.

Open the modal by clicking Stress Test in the top toolbar. The test runs against the URL and method currently configured in the request builder.

The Request Comparison tool runs two endpoint variants simultaneously and presents a structured diff of their responses. It is useful for validating that a refactored endpoint is backward-compatible, comparing staging vs. production behaviour, or checking two different HTTP methods against the same path.

Open the modal by clicking Compare in the top toolbar. The left endpoint defaults to the current request configuration.

Endpoint Configuration

Response Panels

Diff Tabs

The Authorization tab lets you attach authentication credentials to outgoing requests. It supports bearer token authentication via dedicated token fields and allows arbitrary custom authorization headers through a key-value table.

The Backlog Canvas is the project management board of the DPS System. It centralises all development tasks (issues) in a single view, directly linking each issue to its corresponding UI Canvas and GitHub commits. Two views are available: List (tabular) and Kanban (column-based).

Toolbar

Issue Table Columns

The Create New Issue modal collects all essential data for a development task. Required fields are marked with an asterisk. The issue is immediately visible in the backlog list after creation.

Clicking any issue in the list opens the Issue Details panel — a slide-in drawer with five tabs (Details, Committed Files, Issue Relations, Comments, History) and a persistent right sidebar for metadata and actions.

Details Tab

Right Sidebar

The Comments tab enables team collaboration directly on the issue. All comments are persisted and displayed in chronological order below the editor.

Comment Editor

Comment List

The History tab provides a full audit trail of every change made to the issue. Each entry records who did what and when, making it easy to trace the lifecycle of any task.

The Issue Relations tab maps dependencies between issues. Two relation types are supported: Parent Issues (the source task this issue derives from) and Child Issues (follow-up tasks created from this issue).

The Committed Files tab links the issue to its corresponding GitHub commits, showing exactly which code files were changed to resolve it. This creates a traceable connection between a backlog task and its implementation.

The Actions dropdown in the issue sidebar provides quick-access commands for managing the issue lifecycle. A Code Line input below it allows linking the issue to a specific code line count from a commit.

Any issue can be shared via a public URL using the Share button in the issue header. Recipients can view the issue details without requiring a DPS System login.

Clicking the Status badge on an issue row opens the Update Issue Status panel, allowing the status to be changed inline without opening the full issue details.

The Update Issue Type panel is opened via Actions → Update Typeand allows reclassifying the issue without editing the full form.

The Forward Issue(s) panel reassigns the issue to another team member. Accessible via Actions → Forward Issue, it searches all project members and transfers ownership immediately upon confirmation.

Close and Send (via Actions → Close and Send) closes the issue and simultaneously forwards a summary notification to another user. This is typically used when a developer completes a task and hands it off for QA or product review.

The Issue Filter panel lets teams narrow the backlog list by combining multiple criteria simultaneously. Opened via the Filter button in the toolbar, it supports eight filter dimensions across three row groups.

The Commit History panel shows the full diff view for a specific commit linked to an issue. It provides deep visibility into the exact code changes that resolved the task, bridging the gap between backlog tracking and source control.

The GitHub Commits – Not in Backlog modal bridges the gap between code commits and tracked issues. It lists commits from the linked repository that have not yet been associated with any backlog task, allowing them to be retroactively added as issues.

Filter Toolbar

Commit Entries

Switching to the Kanban tab transforms the backlog into a column-based board. Issues are grouped by status, giving teams a visual overview of workflow progress across all active tasks at a glance.

Status Columns

Issue Card

The Code Builder is an integrated GitHub-powered development workspace inside DPS. It lets you browse repositories, view source files, track commit history, and open files in your preferred external editor — all without leaving the platform.

Code Builder bridges the gap between canvas design and actual code execution. Once linked to a GitHub repository, every file in the repo is accessible directly alongside the UI Canvas and API Canvas it was built from.

Before browsing any repository, you must authenticate with GitHub. DPS uses the standard OAuth 2.0 flow — no personal access tokens or SSH keys needed. Authentication is per-user and persists for the session.

Authentication Flow

After authentication the full GitHub Repository Browser becomes active. The left panel shows an expandable directory tree for the selected repository and branch; the right panel renders the selected file with syntax highlighting and line numbers.

Toolbar Elements

File Tree Panel

Code Viewer Panel

The Open in button gives one-click access to five popular development environments. DPS constructs the correct deep-link URL for the active repository and redirects you instantly — no manual URL construction or workspace setup required.

Available Options

Clicking Commit History in the toolbar slides open a full commit log for the active repository. The log is filterable by branch and date range, and each entry summarises what changed and who made the change.

Filter Controls

Commit Entry Anatomy

Clicking N files changed on any commit entry expands the Changed Files list — a per-file breakdown showing the file path, change status badge, and exact line-level statistics. Each file can be opened directly in the code viewer.

Changed Files List

Clicking [Open] on a changed file inside the Commit History launches the File Diff Viewer — an inline code comparison overlay that renders every addition and deletion for that file with colour-coded line highlighting.

Diff Viewer Elements

The GitHub Repositories module is the central place inside a DPS project for linking external GitHub repositories to canvases. Every repository added here becomes available to the Code Builder, Backlog Canvas commit integrations, and any canvas-level GitHub file associations. The page opens on a table listing all connected repositories with their ownership, canvas type, and quick-action controls.

Page Header

Repository Table Columns

Clicking the + Add button on the repository list opens the Add New Github Repository modal. Three fields must be completed before the record can be saved. All fields are required (marked with a red asterisk).

Modal Fields

Clicking the Collaborators button on any repository row opens the GitHub Collaborators modal. It lists every GitHub user who has been granted access to that repository from within DPS, together with their assigned permission levels. Collaborators can be removed individually without affecting the repository record itself.

Modal Elements

UI Canvas Reports is the primary tabular reporting module within the Analytics section of DPS. Unlike UI Canvas Analytics (which uses time-series charts), this page presents a structured table where each row is one UI Canvas (screen) and each column is a key execution metric. A KPI summary row at the top aggregates totals across all visible canvases, giving an instant project-wide health check before drilling into individual screens.

Page Structure

The five KPI cards at the top of UI Canvas Reports provide a single-glance summary of the entire project's execution state. Each card sums the corresponding metric across every UI canvas that is currently visible in the table (i.e., matching the active canvas name filter). Filtering the table updates the cards instantly.

KPI Card Definitions

Between the KPI summary row and the metrics table sits a lightweight toolbar with a real-time text filter and a column sort control. Together they let you quickly navigate a project with many canvases without losing sight of the aggregate KPIs.

The metrics table is the core of UI Canvas Reports. Each row represents one UI Canvas and each column presents a distinct execution metric. Clicking a canvas name navigates to that canvas's detail page for deeper inspection. The table is sortable by any column and updates live when the name filter changes.

Table Columns

Each canvas row in the table contains more than just a single number — it pairs the primary metric value with contextual sub-labels that explain its source and freshness. Understanding these sub-labels prevents misreading raw numbers (e.g., confusing a backlog-aggregate hour count with a Git-commit-aggregate line count).

Cell Sub-labels

UI Canvas Analytics is the canvas-centric counterpart to Assignee Analytics. Instead of grouping metrics by team member, it groups them by UI Canvas — each individual screen in the project (e.g., Login, Menu Page, Settings Screen). The same four chart types are available: closed issues, closed bugs, spent hours, and code lines. All charts share one filter state and refresh together when the Filter button is applied.

Filter Controls

The Number of Closed Issues chart counts how many backlog issues were resolved within the selected date window, broken down by UI Canvas. Each bar represents one canvas and its height reflects the number of closed issues linked to that screen. Canvases with no resolved issues in the period simply have no bar, keeping the chart uncluttered.

Chart Details

The Number of Closed Bugs chart is structurally identical to Closed Issues but counts only backlog items tagged as Bug type, broken down by UI Canvas. When no bugs match the active filters the chart renders an empty-state illustration with guidance text rather than a blank panel.

Chart Details

The Spent Hours chart aggregates the time logged against backlog tasks linked to each UI Canvas in the selected date window. It reveals which screens are consuming the most development effort — a canvas with a tall bar is either complex, blocked, or receiving heavy iterative work.

Chart Details

The Code Lines chart measures the volume of code contributed for each UI Canvas within the selected period. Data is sourced from linked GitHub repositories via the Code Builder integration and counts commit-level line additions, grouped by canvas and time bucket. It is the most direct indicator of raw development output per screen.

Chart Details

The Assignee Analytics module provides a filter-driven reporting dashboard for tracking each team member's contribution across four dimensions: closed issues, closed bugs, spent hours, and code lines. All four charts share the same filter state, so adjusting one control instantly re-renders every widget on the page.

Filter Controls

The Number of Closed Issues chart counts how many backlog issues each assignee resolved within the selected date window. Bars are grouped by time bucket and colour-coded per assignee, making relative output immediately visible without reading exact numbers.

Chart Elements

The Number of Closed Bugs chart mirrors the Closed Issues layout but counts only backlog items tagged as Bug. When no bugs match the active filter combination the chart renders an empty-state illustration rather than a blank or broken chart, prompting the user to try a different date range or selection.

Chart Elements

The Spent Hours chart aggregates the time each assignee has logged against their backlog tasks within the selected date window. It surfaces workload distribution at a glance — a bar that consistently towers over others signals a potential over-allocation risk before it becomes a delivery problem.

Chart Elements

The Code Lines chart measures the volume of code each assignee has contributed within the selected period. Data is sourced from the linked GitHub repositories via the Code Builder integration and counts line additions per commit, grouped by the active time interval.

Chart Elements

User Management is the administration hub for every DPS project. It is accessible only to users with the Admin role and brings together four distinct capabilities on a single page: a live membership summary, a team member list, a project invitation tracker, and a role management panel. Changes made here take effect immediately across the entire project.

Page Sections

The Team Members section lists every user who is currently an active participant in the project. Each member row shows their avatar, display name, email address, assigned role, and two inline action icons. The current logged-in user is marked with a You tag so they can identify their own record at a glance.

The Project Invitations table tracks every email-based invitation sent from this project. Each row records who was invited, which role they were offered, the current acceptance status, and the exact timestamps of creation and acceptance. Admins can resend or revoke invitations at any time using the inline action icons.

Table Columns

The bottom section of User Management is the role registry. It is split into two panels: the built-in System Role (Admin) which cannot be modified, and Custom Roles that project admins create and maintain. Custom roles define which DPS modules a member can access.

System Role

Custom Roles

Clicking + Create New Role opens the Create New Role modal. It allows admins to define a project-specific role with a custom name and a precise set of module permissions. Existing role names are shown at the top as reference to avoid duplicates. User Management is always reserved for admins only and cannot be granted to custom roles.

Modal Fields

Available Module Permissions

The Add Member flow is used to add an existing DPS user directly to the project — without sending an invitation email. The user must already have a DPS account. Clicking + Add Member in the Team Members header opens the Add User to Project modal.

The Invite Member flow sends an email invitation to a user who does not yet have a DPS account. Clicking Invite Member in the Team Members header opens the Invite User to Join Project modal. The invited user receives a secure link, registers a new account, and is automatically added to the project with the specified role upon completion.

The Notification Panel is a slide-in flyout that appears on the right side of any DPS page when the bell icon in the top navigation bar is clicked. It delivers an at-a-glance summary of the most recent activity without navigating away from the current screen. A red badge on the bell icon shows the count of unread notifications.

Panel Elements

The All Notifications page is the complete notification history for the logged-in user within the current DPS project. It lists every system event — issue creation, status changes, assignments, comments, and more — grouped by date and presented in a paginated table. The page header displays the total notification count and unread count at a glance.

Page Header

Notification Row

The filter bar beneath the page header lets you narrow the notification list by project, creator, and date range. Filters work cumulatively — applying more than one narrows the results further. The Clear Filters link resets all controls simultaneously without a page reload.

Filter Controls

Each notification row exposes two inline actions that appear on hover (or are always visible on touch devices). These allow you to act on individual notifications without affecting the rest of the list, giving precise control over your read state and quick access to the related DPS entity.

Row-level Actions