Standup

Standup is a client-side Azure DevOps dashboard for team standup and quality-assurance tracking. It helps a team review current sprint work, monitor work-item flow, spot recently changed items, and surface pull requests that are not already attached to visible work items.

The app is a browser-based React + TypeScript single-page app. It does not have a backend service; it calls the Azure DevOps REST API directly from the browser using a personal access token (PAT).

What the app does

Team assignments view

The default view is a standup-style Kanban board that:

• loads team members and sprint work items from Azure DevOps
• groups work items by assignee and status
• shows sprint context and delivery progress in a compact board layout
• applies quick text filters, member filters, hidden-tag rules, and type filters
• highlights recent changes or project-specific work-item activity
• adds PR-only cards for pull requests in the selected repository that are not already linked to visible work items

Quality assurance view

The QA activity page surfaces recently created and changed work items for review, with:

• sprint and lookback filters
• state grouping and tag-based grouping
• work-item type filters
• a compact review board for QA triage

States can be shared between Needs follow-up and Newly added. For these shared states, a recent transition into a QA-ready state takes precedence and routes the item to Needs follow-up. Otherwise, items created within the lookback window appear in Newly added. Ready for QA and Recently completed state precedence, and explicit tag-based grouping, are unchanged.

Tests view

The Tests page charts e2e pass percentages across a configurable lookback window (90 days by default) for each configured Azure DevOps build/YAML pipeline or classic release pipeline. Use Tests settings to set the number of days, enter the organization and project, type to search pipelines and stages, choose a test-publishing stage (or the whole build pipeline), and add it to the chart. The lookback window is saved in browser local storage and applies to all configured pipelines. Build history is filtered by finish time; release history is queried by creation time, then charted by the selected stage's completion time when available. Multiple pipelines appear as separate lines. Each point represents one run, including multiple runs on the same day; the x-axis shows dates and tooltips show exact times and run IDs. Click a point to open its build Tests tab or release summary in a new tab. The y-axis uses a logarithmic scale of failures (with a 1% offset for 100% pass rates), labeled in pass percentages to make differences near 100% easier to see. Each point is passed tests divided by executed test results, excluding NotExecuted, Skipped, NotApplicable, and NotImpacted. Tests must be published to Azure DevOps for the chart to find them; stages without executed test results are shown as missing data, not 0% passed. If test results cannot be loaded, the page or settings dialog reminds you to ensure your PAT has Test Management (Read) access. The refresh button reloads the latest results. Tests has no filter, view, or team controls; pipeline selections are saved in browser local storage.

Tests settings uses two tabs: Options contains the lookback window, and Pipelines contains the configured pipeline list and controls for adding or removing pipelines. Options also includes an optional pass rate filter (unchecked by default). Enable it and enter a percentage from 0 to 100 inclusive to hide chart points at or below that pass rate. For example, 0 excludes 0% results and 20 excludes results at 20% or lower; 100 hides all results. Decimal thresholds are supported. The setting is saved in browser local storage and applies to all configured pipelines without refetching results. Disabling it restores the hidden points. Options also includes "Show at most one result per pipeline per day" (unchecked by default). Choose Lowest result, Average result, or Highest result. Days use the browser's local timezone, and the pass rate filter is applied to individual runs before grouping. Average is the arithmetic mean of run percentages, not weighted by test count. Multi-run averages have no run link; single-run days and lowest/highest selections retain their original run links. Ties select the earliest run (then the lowest run ID). Daily options are saved in browser local storage.

Run the Tests data regression tests with node --experimental-strip-types --test tests/*.test.ts.

Team configuration

Each team profile includes the Azure DevOps organization, project, area path, iteration path, team name, and repository. Teams can be managed in the UI and exported/imported as JSON for sharing between teammates.

Tech stack

• React 19
• TypeScript
• Vite 8
• Material UI + Emotion
• StrataKit UI components and icons

Repository structure

src/
  App.tsx                  # top-level app shell and persistence
  ado/                     # Azure DevOps API helpers and query logic
  features/standup/        # board, QA, Tests, and team-management UI
  adoAuth.ts               # PAT storage and validation
  appSettings.ts           # persisted app settings and team profiles
  teamDataTransfer.ts      # team export/import helpers
public/                   # static assets
index.html                # app entry document
vite.config.ts            # Vite configuration

Requirements

• Node.js 22+
• npm 10+
• An Azure DevOps account and PAT with read access to work items, pull requests, project/team metadata, and related APIs

Azure DevOps PAT requirements

The app validates a PAT before loading data. Required scopes include:

• Build (Read)
• Code (Read)
• Graph (Read)
• Project and Team (Read)
• Release (Read)
• Test Management (Read)
• Work Items (Read)

The Graph read scope is needed for resolving a team subjectDescriptor when building the direct "Manage team" deep link. If it is not available, the app falls back to the project team listing page.

Getting started

1) Install dependencies

npm install

2) Start the app in development mode

npm run dev

Then open the local Vite URL shown in the terminal, usually:

http://localhost:5173

3) Configure the PAT and team

On first launch:

1. open the app
2. provide your Azure DevOps PAT in the settings dialog
3. choose whether to remember it on this machine or keep it only for the current browser session
4. select or configure a team profile from Settings > Teams

PAT and team settings are kept in the browser local storage/session storage, so the app is intentionally a single-user browser client rather than a multi-user service.

Team configuration

Team definitions are stored per profile and include:

• org name
• project name
• display name
• area path
• iteration path
• team name
• repository name

The selected team is persisted automatically and restored when the app loads.

Importing and exporting team data

From Settings > Teams, you can:

• export the selected team's configuration and saved page options as a JSON file
• import a JSON export from another teammate or environment

The import path validates the payload before applying it, so malformed data is rejected rather than silently corrupting local settings.

Features and workflows

Filtering and navigation

• quick text filter across work item IDs, titles, types, sprint labels, tags, PR IDs, PR titles, and assignee names
• member filter for the current board
• hidden-tag filters persisted per team
• board toggles for work-item types and sprint scope
• keyboard shortcut: Ctrl/Cmd + F focuses the quick filter on Development and Quality Assurance
• navigation between Development, Quality Assurance, and Tests pages

Pull request behavior

• queries active and completed PRs from the selected repository
• excludes drafts and abandoned PRs
• only includes completed PRs created within the current sprint window
• suppresses PR-only cards when the PR is already linked to a visible work item

UX details

• board loading uses a skeleton layout to keep the page stable while data loads
• the board header and content share one scroll container for alignment
• dense columns can collapse and expand groups for easier sprint review
• light/dark visual mode is supported

Development commands

npm run dev      # start Vite dev server
npm run build    # compile TS and create a production build
npm run lint     # run project linting
npm run preview  # preview the production Vite build locally

Notes for contributors

• The app is intentionally frontend-only and reads Azure DevOps data directly in the browser.
• Team preferences are stored in localStorage and are keyed by team ID, so multiple team profiles can co-exist without overwriting each other's saved filters or options.
• The StrataKit app root is wrapped in src/main.tsx, and the repository includes a local skill under .github/skills/stratakit-usage/SKILL.md for UI work that should follow StrataKit conventions.

Security and privacy considerations

• The PAT is stored in browser storage only, not on a server.
• A session-only PAT is possible for temporary usage without persisting credentials to disk.
• This app is best suited for internal or trusted environments where browser-side Azure DevOps access is acceptable.