@tecafrik/africa-payment-sdk/.kiro/specs/ci-cd-pipeline-separation/requirements.md

A single SDK to integrate all african payment providers seamlessly

# Requirements Document

## Introduction

This feature aims to improve the CI/CD pipeline by separating build and publish into distinct jobs within a single workflow. Currently, the pipeline runs both build and publish steps on every push and pull request to the main branch, which means packages could be published on pull requests. The goal is to ensure that build validation runs on all changes (pushes and PRs), while publishing only occurs on direct pushes to the main branch by conditionally skipping the publish job on pull requests.

## Requirements

### Requirement 1

**User Story:** As a developer, I want the build and test pipeline to run on all pull requests and pushes to main, so that I can validate code quality before merging.

#### Acceptance Criteria

1. WHEN a pull request is opened or updated targeting the main branch THEN the system SHALL execute the build workflow
2. WHEN code is pushed directly to the main branch THEN the system SHALL execute the build workflow
3. WHEN the build workflow runs THEN the system SHALL install dependencies, run tests, and build the project
4. WHEN the build workflow completes THEN the system SHALL report success or failure status

### Requirement 2

**User Story:** As a maintainer, I want packages to be published only on direct pushes to main (not on pull requests), so that I can control when new versions are released to npm.

#### Acceptance Criteria

1. WHEN code is pushed directly to the main branch THEN the system SHALL execute the publish workflow after the build workflow succeeds
2. WHEN a pull request is merged or updated THEN the system SHALL NOT execute the publish workflow
3. WHEN the publish workflow runs THEN the system SHALL publish the package to npm with public access
4. IF the build workflow fails THEN the system SHALL NOT execute the publish workflow

### Requirement 3

**User Story:** As a developer, I want the build and publish jobs to be clearly separated within a single workflow, so that I can easily understand which steps are running and troubleshoot issues.

#### Acceptance Criteria

1. WHEN viewing GitHub Actions THEN the system SHALL display separate jobs for "Build" and "Publish" within the same workflow run
2. WHEN the workflow runs THEN the system SHALL use descriptive names for jobs and steps
3. WHEN the publish job depends on the build job THEN the system SHALL clearly indicate this dependency using the `needs` keyword
4. WHEN a pull request triggers the workflow THEN the system SHALL skip the publish job
5. WHEN viewing workflow logs THEN the system SHALL provide clear output for each step and indicate when jobs are skipped