Watchtower-Course-Project

WatchTower Workflow Guide

1) Purpose

This document defines how the WatchTower team plans, tracks, builds, reviews, and closes work in GitHub for Sprint 1 and future sprints. It keeps team execution consistent, transparent, and easy to follow for a class project environment.

2) Sprint 1 Focus and Deadline

3) Repository Workflow Steps

  1. Create or select a GitHub issue from the backlog.
  2. Confirm issue labels (sprint, priority, type, status) and owner/support/reviewer fields.
  3. Create a branch from main using branch naming conventions.
  4. Implement one scoped change per branch.
  5. Commit using Conventional Commits.
  6. Push branch and open a pull request linked to the issue.
  7. Request review and address feedback.
  8. Merge only after acceptance criteria are met and reviewer approval is received.
  9. Update issue status labels and close the issue.

4) Branch Naming Convention

Use short, descriptive branch names:

Examples:

5) Conventional Commit Format

Use this format:

<type>: <short summary>

Common types:

Examples:

6) Pull Request Expectations

Every major change goes through a pull request.

Each PR must include:

PR checklist expectations:

7) GitHub Issue Body Convention

Use this body format for all backlog issues:

Minimum rule: every issue must include Owner, Support, and Reviewer in the issue body.

8) Owner / Support / Reviewer Definitions

9) Label Conventions

Use labels from all required groups for each issue.

Sprint Labels

Priority Labels

Type Labels

Status Labels

10) Sprint 1 Backlog Expectations

11) Future Placeholder Issue Expectations

Add placeholder issues for future work so the roadmap is visible early. Placeholders should include:

Each placeholder must still include labels, owner/support/reviewer, and acceptance criteria even if implementation is in a later sprint.

12) Backlog Review Requirement

The backlog must be reviewed at least once during a team sync. During the review:

13) Standup Expectations

Team members provide regular standup updates (live or async) using:

Standup updates should reference active issue numbers when possible.

14) Documentation Folder Structure

Use docs/ as the primary project documentation directory:

15) GenAI Usage Convention

GenAI tools are allowed for brainstorming, drafting, and code/documentation assistance with the following rules:

16) Definition of Done (Project-Wide)

A task is done when:

17) Sprint 1 Definition of Done

Sprint 1 is done when:

18) Continuous Integration & Quality Pipeline

Every push to main and every pull request targeting main runs the GitHub Actions workflow defined in .github/workflows/ci.yml. The pipeline is structured as small, independent jobs so failures point directly at the responsible area of the codebase.

CI Jobs

Dependency philosophy

Running the pipeline locally

npm install
npm run test:unit       # Jest unit tests
npm run docs:js         # generate docs/api/
npm start               # start the WatchTower server on :3000
npm run test:e2e        # Playwright smoke tests (in a separate terminal)

19) Communication Expectations