3.0: Workflow Instructions

Purpose and Scope

For AI Agents Working with Version Control

Audience: AI agents executing ASPICE tasks integrated with version control systems (Git, GitHub, GitLab, Bitbucket)

Purpose: Provide workflow instructions for:

  1. Git Operations: Branch creation, commits, merges
  2. Pull Request Workflow: PR creation, review, approval, merge
  3. Testing Workflow: CI/CD integration, test execution, coverage reporting
  4. Release Workflow: Versioning, tagging, release notes, artifacts

Why Workflows Matter:

  • Traceability: Git commits link code changes to requirements and issues
  • Quality Gates: Pull requests enforce human review (HITL)
  • Reproducibility: Tagged releases enable auditing (ASPICE compliance)
  • Automation: CI/CD pipelines run tests and checks automatically

Workflow Overview

AI Agent Integration with SDLC

The following diagram provides an overview of how AI agents integrate into the standard SDLC workflow, showing the handoff points between automated AI tasks and human approval gates.

Workflow Overview

Key Principle: AI automates, humans approve (HITL enforced at PR review and release approval)

Workflow Exception Handling: Standard workflow exceptions: (1) Hotfix path (bypasses feature freeze), (2) Security patch (expedited review), (3) Documentation-only (reduced testing). Document exception approval in PR description and notify relevant stakeholders.


Workflow Standards

Universal Rules for All AI Agents

1. Branching Strategy: Feature Branch Workflow (GitFlow-lite)

  • Main Branch: main (production-ready, protected)
  • Feature Branches: feature/ASPICE-1234-short-description
  • Hotfix Branches: hotfix/v1.2.1-critical-bug
  • Release Branches: release/v1.2.0 (optional, for release preparation)

2. Commit Message Format: Conventional Commits

<type>(<scope>): <short description> [<issue-id>]

<body (optional)>

<footer (optional)>

Example:

feat(acc): Implement obstacle distance calculation [ASPICE-1234]

- Add ACC_GetObstacleDistance() function
- Implements [SWE-045-1] from requirements spec
- MISRA C:2012 compliant (0 violations)

Reviewed-by: @senior_engineer

Commit Types:

  • feat: New feature (SWE.3 implementation)
  • fix: Bug fix (SUP.9 problem resolution)
  • docs: Documentation update (SUP.1)
  • test: Test addition/modification (SWE.4)
  • refactor: Code refactoring (no behavior change)
  • style: Code style/formatting (MISRA, clang-format)
  • chore: Build, CI/CD, dependencies

3. Pull Request Requirements:

  • [PASS] Title: Clear, concise (e.g., "Implement ACC controller [ASPICE-1234]")
  • [PASS] Description: Summary, traceability, human action required
  • [PASS] Labels: Type (feat/fix/docs), priority (high/medium/low), ASPICE process (SWE.3)
  • [PASS] Reviewers: Assign human reviewer (architect, engineer, tester)
  • [PASS] Linked Issues: Link to Jira/GitHub issue (ASPICE-1234)

4. CI/CD Pipeline Stages:

stages:
  - build       # Compile code
  - test        # Unit tests, coverage
  - analyze     # MISRA, static analysis
  - review_prep # Generate review reports
  - deploy      # (After merge) Deploy to target

Traceability in Workflows

Linking Code to Requirements

Traceability Chain: Issue → Branch → Commit → PR → Code → Test → Release

Example Traceability Flow:

  1. Issue: ASPICE-1234 "Implement ACC obstacle distance calculation [SWE-045-1]"
  2. Branch: feature/ASPICE-1234-acc-distance
  3. Commit: feat(acc): Implement distance calculation [ASPICE-1234]
  4. Code: Function with @implements [SWE-045-1] tag
  5. Test: TC-SWE-045-1-1 verifies [SWE-045-1]
  6. PR: Links to issue ASPICE-1234, references requirement [SWE-045-1]
  7. Release: v1.2.0 release notes mention "Implemented [SWE-045-1]"

Benefit: TÜV/FDA assessor can trace requirement → code → test → release (full ASPICE compliance)


Workflow Sections

Detailed Instructions by Workflow Type

Section Workflow Type Primary Actions
31.01 Pull Request Workflow PR creation, review, approval, merge
31.02 Testing Workflow CI/CD pipeline, test execution, reporting
31.03 Release Workflow Versioning, tagging, release notes, artifacts

Read section-specific instructions for detailed guidance


Quality Gates in Workflows

Enforcement Points for ASPICE Compliance

Quality Gate 1: Pre-Commit (AI Self-Check)

  • [PASS] Code compiles without errors
  • [PASS] MISRA check passes (0 Required violations)
  • [PASS] Unit tests pass (100% of generated tests)
  • [PASS] Traceability tags present (@implements)

Quality Gate 2: CI/CD Pipeline (Automated)

  • [PASS] Build succeeds (gcc, warnings-as-errors)
  • [PASS] Unit tests pass (100%)
  • [PASS] Coverage ≥ 80% (target 100%)
  • [PASS] Static analysis clean (cppcheck, PC-lint)

Quality Gate 3: Human Review (HITL Gate)

  • [PASS] Code correctness verified by senior engineer
  • [PASS] Safety logic approved by safety engineer (if ASIL-B/C)
  • [PASS] Traceability verified by requirements engineer
  • [PASS] PR approved by designated reviewer

Quality Gate 4: Release Approval (Human)

  • [PASS] All PRs for release merged and tested
  • [PASS] System-level tests passed (HIL, proving ground)
  • [PASS] Release notes reviewed by project manager
  • [PASS] Artifacts signed by release manager

Gate Failure Actions:

  • Gate 1 Failure: AI fixes issues, re-runs checks (no commit)
  • Gate 2 Failure: CI/CD blocks PR, AI escalates to human
  • Gate 3 Failure: Human requests changes, AI revises code
  • Gate 4 Failure: Release postponed, critical issues addressed

Safety-Critical Commit Requirements

ASIL-B/C/D Commit Template

For safety-classified code, include verification evidence directly in the commit message:

<type>(<scope>): <summary> [<issue-id>]

SAFETY-CRITICAL COMMIT:
- Function: <function_name> (<ASIL level>)
- MISRA C:2012: <violations count> [PASS/FAIL]
- Unit test coverage: <percentage> [PASS/FAIL]
- Static analysis: <issues count> [PASS/FAIL]

Implements: [<requirement-id>] (<ASIL level>)
Safety-Reviewed-By: TBD (human approval required)

Signed-off-by: <AI agent name>

Note: The Safety-Reviewed-By: TBD field is mandatory for ASIL-B and above. It must be filled by a human safety engineer before the PR can be merged. This enforces the HITL gate for safety-critical code.

Binary Artifacts

For binary files (test vectors, calibration data, generated binaries >1MB), use Git LFS:

git lfs install && git lfs track "*.bin" "*.hex" "*.elf"

This prevents repository bloat while maintaining version control for binary artifacts required for ASPICE traceability.


Common Workflow Patterns

Standard Sequences for AI Agents

Pattern 1: Feature Implementation

1. Pull latest main branch
2. Create feature branch (feature/ASPICE-1234-...)
3. Implement code (SWE.3)
4. Write unit tests (SWE.4)
5. Run local checks (MISRA, tests)
6. Commit with traceability message
7. Push branch to remote
8. Create pull request
9. Wait for CI/CD + human review
10. Address review comments (if any)
11. PR merged by human → feature complete

Pattern 2: Bug Fix

1. Reproduce bug (create failing test case)
2. Create hotfix branch (hotfix/v1.2.1-bug-description)
3. Fix code (minimal changes)
4. Verify test now passes
5. Commit with "fix:" prefix [ISSUE-ID]
6. Create PR with priority:high label
7. Fast-track review (critical bug)
8. Merge to main + backport to release branch (if needed)

Pattern 3: Documentation Update

1. Create docs branch (docs/update-srs)
2. Update documentation (SRS, SAD, test reports)
3. Commit with "docs:" prefix
4. Create PR (fast review, low risk)
5. Merge without extensive testing (docs-only change)

Summary

Workflow Instructions Overview:

  1. Git Workflow: Branch strategy, commit conventions, push/merge operations
  2. Pull Request Workflow: PR creation, review cycle, approval, merge
  3. Testing Workflow: CI/CD integration, test execution, coverage reporting
  4. Release Workflow: Versioning, tagging, release notes, artifact generation

Quality Gates: 4 levels (pre-commit, CI/CD, human review, release approval)

Traceability: Issue → Branch → Commit → PR → Code → Test → Release

Next: Pull Request Workflow (31.01)