new pipelines - still WIP

[hanneshapke]

Description

Linked Issue

Closes #

Type of Change

• Bug fix
• New feature
• Refactor / code quality
• Documentation update
• CI / build change

Testing Done

Unit tests (Go):

make test-go

Unit tests (Python):

make test

Linting & type checks:

make lint
make typecheck

Manual testing (if applicable):

• Describe the scenario tested (e.g. PII type detected, proxy request flow, Chrome extension behavior)
• Include before/after behavior if fixing a bug
• Note any edge cases verified (e.g. nested PII in JSON payloads, restoration accuracy)

Checklist

• make test-go and make test pass locally
• make lint reports no new errors
• New PII detection changes are covered by unit tests in tests/
• Go proxy changes include test coverage in src/ or model/
• Documentation updated if behavior or configuration changed
• No sensitive data or credentials included

[github-actions]

Warning

PR title does not follow the Conventional Commits specification.

No release type found in pull request title "new pipelines - still WIP". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

• feat
• fix
• docs
• style
• chore
• refactor
• test
• ci
• perf
• deps

---

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

More Examples:

• feat: (new feature for the user, not a new feature for build script)
• fix: (bug fix for the user, not a fix to a build script)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)
• deps: (dependency updates, e.g. bumping package versions)

The <scope> (sub-type) is optional and may be any value, e.g. feat(linux):, fix(verify-linux):, deps(npm):.

References:

• https://www.conventionalcommits.org/
• https://seesparkbox.com/foundry/semantic_commit_messages
• http://karma-runner.github.io/1.0/dev/git-commit-msg.html