What
Annotation names currently only accept word characters, 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.
Where
app/controlplane/api/workflowcontract/v1/crafting_schema.proto:
message Annotation {
string name = 1 [(buf.validate.field).string.pattern = "^[\\w]+$"]; // Single word optionally separated with _
// This value can be set in the contract or provided during the attestation
string value = 2;
}^[\w]+$ matches letters, digits and underscore. Hyphen is not in the class.
Suggested change
Widen the pattern to allow hyphens, keeping it consistent with how other names are validated, and update the trailing comment so it no longer says underscores only.
Things to check while making the change:
- Regenerate the protobuf code after editing the
.proto (the generated Go must be committed alongside it).
- Annotation names flow into the integrations engine for filtering and interpolation — confirm a hyphenated name survives that path.
- Add a test case covering a hyphenated name, and one confirming genuinely invalid names are still rejected.
- Existing underscore names must keep working; this is purely additive.
Why it is a good first issue
The change itself is one line in a .proto. The value is in doing it properly: regenerating, testing both the new and existing cases, and checking nothing downstream assumed the narrower character set.
What
Annotation names currently only accept word characters, so
my_annotationis valid butmy-annotationis 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.Where
app/controlplane/api/workflowcontract/v1/crafting_schema.proto:^[\w]+$matches letters, digits and underscore. Hyphen is not in the class.Suggested change
Widen the pattern to allow hyphens, keeping it consistent with how other names are validated, and update the trailing comment so it no longer says underscores only.
Things to check while making the change:
.proto(the generated Go must be committed alongside it).Why it is a good first issue
The change itself is one line in a
.proto. The value is in doing it properly: regenerating, testing both the new and existing cases, and checking nothing downstream assumed the narrower character set.