docs: add PROCESS.md — QMS compliance workflow for GitHub/Jira/Ketryx/Confluence [PYSDK-81]#566
docs: add PROCESS.md — QMS compliance workflow for GitHub/Jira/Ketryx/Confluence [PYSDK-81]#566helmut-hoffer-von-ankershoffen wants to merge 1 commit into
Conversation
Documents how GitHub PRs, Jira anomaly/change-request tickets, Ketryx releases, and Confluence SOPs (PR-SOP-01, CC-WI-01) relate and must be linked bidirectionally for regulatory compliance. Also describes expected Claude Code behaviour when creating PRs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
helmut-hoffer-von-ankershoffen
added
the
skip:test:long_running
|
There was a problem hiding this comment.
Pull request overview
Adds a repository-level engineering process guide describing how GitHub PRs, Jira tickets (Anomaly + Change Request), Ketryx releases, and Confluence QMS SOPs fit together for compliance/traceability.
Changes:
- Introduces
PROCESS.mdwith step-by-step workflows for Anomaly → PR and Change Request → PR. - Documents Ketryx release phases and how release approval depends on Jira item status/approvals.
- Adds quick-reference guidance and a “Claude Code workflow” section to standardize AI-assisted PR behavior.
| | **Ketryx** | Regulated release management — links Jira tickets to releases, collects approvals, enforces traceability | | ||
| | **Confluence (QMS)** | SOPs and work instructions that define the mandatory processes | | ||
|
|
||
| Ketryx sits on top of Jira: it reads Jira tickets of specific types (Anomaly, Change Request) and enforces that they are approved and linked before a release can be closed. A Ketryx release cannot be approved unless all linked items in Jira are in `Closed` status with the required approvals. |
There was a problem hiding this comment.
This line refers to Jira ticket types as “(Anomaly, Change Request)”, but later the document specifies the Jira issue type name as Ketryx Change Request. To avoid confusion about the exact Jira issue type Ketryx expects, consider using consistent terminology here (e.g., “Anomaly” and “Ketryx Change Request (Jira issue type)”).
| Ketryx sits on top of Jira: it reads Jira tickets of specific types (Anomaly, Change Request) and enforces that they are approved and linked before a release can be closed. A Ketryx release cannot be approved unless all linked items in Jira are in `Closed` status with the required approvals. | |
| Ketryx sits on top of Jira: it reads Jira tickets of specific types (Anomaly, Ketryx Change Request) and enforces that they are approved and linked before a release can be closed. A Ketryx release cannot be approved unless all linked items in Jira are in `Closed` status with the required approvals. |
| - Title: follow conventional commits (fix: ...) | ||
| - PR body: include link to the Jira Anomaly ticket | ||
| Example: "Resolves PYSDK-78: https://aignx.atlassian.net/browse/PYSDK-78" | ||
| - Add label: skip:test:long_running |
There was a problem hiding this comment.
The instruction to add the skip:test:long_running label is phrased as unconditional. Repo guidance elsewhere frames this as a time-saver “unless you need long tests” (see .github/CLAUDE.md:1008). Consider adding that caveat here so PRs that require long-running coverage don’t accidentally skip it.
| - Add label: skip:test:long_running | |
| - Add label: skip:test:long_running unless this PR needs long-running test coverage |
| 4. Create GitHub PR | ||
| - PR description: link to the CR ticket | ||
| Example: "Implements PYSDK-CR-XX: https://aignx.atlassian.net/browse/PYSDK-XX" | ||
| - Add label: skip:test:long_running |
There was a problem hiding this comment.
Same as Process 1: recommending skip:test:long_running as an unconditional step may lead to skipping needed long-running coverage. Consider mirroring the repo guidance (e.g. .github/CLAUDE.md:1008) by framing this as optional “unless you need long tests”, or by stating when it should/shouldn’t be applied.
| - Add label: skip:test:long_running | |
| - If long-running tests are not needed for this change, add label: skip:test:long_running | |
| - Do not add this label when the change requires long-running test coverage |
|
|
||
| 4. Create GitHub PR | ||
| - PR description: link to the CR ticket | ||
| Example: "Implements PYSDK-CR-XX: https://aignx.atlassian.net/browse/PYSDK-XX" |
There was a problem hiding this comment.
In the Change Request PR example, the ticket key in the text ("PYSDK-CR-XX") doesn’t match the Jira URL (currently points to /browse/PYSDK-XX). This makes the copy/paste example incorrect; align the URL with the same ticket key used in the example text (or change the example text to match the URL).
| Example: "Implements PYSDK-CR-XX: https://aignx.atlassian.net/browse/PYSDK-XX" | |
| Example: "Implements PYSDK-CR-XX: https://aignx.atlassian.net/browse/PYSDK-CR-XX" |
| - Add label: skip:test:long_running | ||
|
|
||
| 5. Link PR back in Jira | ||
| - Add PR URL to "Resolved by" or as a comment on the CR ticket |
There was a problem hiding this comment.
For Change Requests, step 5 says the PR URL can be added to "Resolved by" or as a comment. Earlier the doc describes bidirectional traceability as a required mechanism via the dedicated field ("Resolved by"). To avoid ambiguity (and potential compliance/tooling gaps), please specify the single required location/field for CR → PR linking, or explicitly document which options are accepted and why.
| - Add PR URL to "Resolved by" or as a comment on the CR ticket | |
| - Add the PR URL to the CR ticket's "Resolved by" field | |
| - A Jira comment may be added for extra context, but it does not replace the required "Resolved by" link |
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project status has failed because the head coverage (63.77%) is below the target coverage (70.00%). You can increase the head coverage or adjust the target coverage.
|
helmut-hoffer-von-ankershoffen
assigned
helmut-hoffer-von-ankershoffen and unassigned
helmut-hoffer-von-ankershoffen
helmut-hoffer-von-ankershoffen
changed the title
Implements PYSDK-81
Summary
PROCESS.mddocumenting how GitHub PRs, Jira (Anomaly + Change Request tickets), Ketryx releases, and the Confluence-based QMS (PR-SOP-01, CC-WI-01) relate and must be used together for regulatory complianceWhy
Engineers and AI assistants working in this repo need a single place to understand the compliance obligations — particularly the bidirectional linking requirement between GitHub PRs and Jira tickets — without having to read through multiple Confluence SOPs.
Test plan
PROCESS.mdfor accuracy against PR-SOP-01 and CC-WI-01PYSDK) and ticket URLs are correct🤖 Generated with Claude Code