fix(annotations): allow hyphens in annotation names

[yunaremaia]

Summary

• Allow hyphens in Annotation.name by widening the validation pattern from ^[\w]+$ to ^[\w-]+$
• Regenerate the protobuf code (Go), TypeScript definitions, and JSON Schema files
• Update the test suite: hyphen and mixed hyphen-underscore names are now valid; genuinely invalid names (e.g., containing @) are still rejected

Motivation

Annotation names currently only accept word characters ([a-zA-Z0-9_]), so my_annotation is valid but my-annotation is rejected. Contract names and material names both allow hyphens, so this is an inconsistency rather than a deliberate restriction. Users coming from either of those naturally reach for a hyphen and get a validation error.

Fixes #3405

Changes

• app/controlplane/api/workflowcontract/v1/crafting_schema.proto — one-line change to the buf.validate.field pattern
• app/controlplane/api/workflowcontract/v1/crafting_schema.pb.go — regenerated
• app/controlplane/api/gen/frontend/workflowcontract/v1/crafting_schema.ts — regenerated
• app/controlplane/api/gen/jsonschema/workflowcontract.v1.Annotation.jsonschema.json — regenerated
• app/controlplane/api/gen/jsonschema/workflowcontract.v1.Annotation.schema.json — regenerated
• app/controlplane/api/workflowcontract/v1/crafting_schema_test.go — updated existing test + added two new cases

Test Plan

• go test ./app/controlplane/api/workflowcontract/v1/ passes (all 9 annotation test cases pass)
• Existing underscore names still work
• New hyphen names now accepted
• Genuinely invalid names (e.g., @) still rejected

[chainloop-platform]

Security Checks — ✅ 9 passing

✅ secret-scan

Status	Policy	Messages
✅ Passed	secrets-detection	-

✅ sast-scan

Status	Policy	Messages
✅ Passed	cwe-top26-40-cusp	-
✅ Passed	owasp-top10-2025	-
✅ Passed	sast	-
✅ Passed	cwe-top25	-

✅ iac-scan

Status	Policy	Messages
✅ Passed	iac-misconfiguration	-

PR info

Status	Policy	Messages
✅ Passed	pr-min-approvals	-
✅ Passed	pr-description-required	-
✅ Passed	pr-user-story-linked	-

⏭️ 2 scans not applied

Scan	Reason
vulnerability-scan	no manifest/lockfile changed
github-actions-scan	no workflow files changed

View attestation ↗

---

Powered by Chainloop and Chainloop Trace

[cubic-dev-ai]

All reported issues were addressed across 6 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[chrisriv10]

Nice work. I was working on #3405 too and noticed one downstream case that may be worth testing.

Dependency-Track uses annotation keys for filtering and interpolation. Hyphenated keys work for exact filters and templates can access them with: {{ index .Material.Annotations "my-annotation" }}

Since the issue mentions confirming that path, a small test there could be useful.

[yunaremaia]

Thanks @cubic-dev-ai for the review. Valid concern about hyphenated keys in Go template field access. I'll address this by adding documentation to the proto comment noting that hyphenated annotation names require the index template function syntax in integrations like dependency-track. The schema change itself is still correct — it's the template consumer that needs the syntax adjustment.

[cubic-dev-ai]

Thanks @cubic-dev-ai for the review. Valid concern about hyphenated keys in Go template field access. I'll address this by adding documentation to the proto comment noting that hyphenated annotation names require the index template function syntax in integrations like dependency-track. The schema change itself is still correct — it's the template consumer that needs the syntax adjustment.

@yunaremaia Agreed, that's the right call. Widen the pattern in the schema is correct — the restriction was never deliberate, and it keeps annotation names consistent with contract/material names. Hyphenated keys only break down at template interpolation time, so a comment flagging {{ index .Material.Annotations "my-annotation" }} in dependency-track (and similar consumers) is exactly where the guidance belongs. Matches the team's convention of documenting non-obvious behavior inline rather than hiding it.

One small thing worth keeping in mind as you write it: since the proto comment in crafting_schema.pb.go is regenerated, make sure the note lives in the .proto source (which it sounds like you plan to do) so it survives a regen and stays in sync.

_{Tip: get faster answers by chatting with cubic’s review copilot in the review UI}

[migmartri]

Thanks @yunaremaia for the contribution, could you please sign the commit

and perform a sign-off too, thanks!

https://github.com/chainloop-dev/chainloop/blob/main/CONTRIBUTING.md#commit-format

[yunaremaia]

Thanks @migmartri — done. Both commits now carry a sign-off trailer and are GPG-signed:

• Key: 5CA4D4C4410B322E (fingerprint AD0B 1E4A 2A4B 2E3D 005F 5FCB 5CA4 D4C4 410B 322E)
• Public key: https://gist.github.com/yunaremaia/98e812b43522e77cd6c040883009fdb8

One note: the key was freshly generated on my signing machine and is not yet registered under my GitHub account settings, so the badge may show Unverified until then. You can verify manually with gpg --import plus git verify-commit <sha>. Let me know if anything else is needed.

[yunaremaia]

Hi @migmartri — gentle bump on PR #3406. Both commits are now signed-off and GPG-signed (key 5CA4D4C4410B322E). Public key published at the gist linked in the thread. Let me know if anything else is needed. Thanks!

[migmartri]

Thanks @migmartri — done. Both commits now carry a sign-off trailer and are GPG-signed:

• Key: 5CA4D4C4410B322E (fingerprint AD0B 1E4A 2A4B 2E3D 005F 5FCB 5CA4 D4C4 410B 322E)
• Public key: https://gist.github.com/yunaremaia/98e812b43522e77cd6c040883009fdb8

One note: the key was freshly generated on my signing machine and is not yet registered under my GitHub account settings, so the badge may show Unverified until then. You can verify manually with gpg --import plus git verify-commit <sha>. Let me know if anything else is needed.

I am afraid we can't merge until the public key is in your GitHub profile, thanks

[yunaremaia]

Hi @migmartri — I noticed the latest notification (id 25511563947) mentions this PR. It looks like the automated cubic-dev-ai review flagged the Go template field-access concern for hyphenated annotation names in dependency-track integrations. I already addressed this in the proto comment (documenting the template syntax requirement). Is there anything else blocking merge? Thank you!

[migmartri]

Hi @migmartri — I noticed the latest notification (id 25511563947) mentions this PR. It looks like the automated cubic-dev-ai review flagged the Go template field-access concern for hyphenated annotation names in dependency-track integrations. I already addressed this in the proto comment (documenting the template syntax requirement). Is there anything else blocking merge? Thank you!

Yes, please add the public key in your GitHub profile so we can verify it, thanks

[yunaremaia]

Hi @chainloop-dev — CI is fully green (DCO ✅, Kusari ✅, cubic AI review ✅). Ready to merge when you get a chance. Thanks!

[yunaremaia]

Hi @migmartri — thank you for approving this PR! It's been approved since yesterday and all checks are green. Could you merge when you have a moment? Thanks!