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:
- Git Operations: Branch creation, commits, merges
- Pull Request Workflow: PR creation, review, approval, merge
- Testing Workflow: CI/CD integration, test execution, coverage reporting
- 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.
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:
- Issue:
ASPICE-1234"Implement ACC obstacle distance calculation [SWE-045-1]" - Branch:
feature/ASPICE-1234-acc-distance - Commit:
feat(acc): Implement distance calculation [ASPICE-1234] - Code: Function with
@implements [SWE-045-1]tag - Test:
TC-SWE-045-1-1verifies[SWE-045-1] - PR: Links to issue
ASPICE-1234, references requirement[SWE-045-1] - 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: TBDfield 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:
- Git Workflow: Branch strategy, commit conventions, push/merge operations
- Pull Request Workflow: PR creation, review cycle, approval, merge
- Testing Workflow: CI/CD integration, test execution, coverage reporting
- 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)