Problem
In gh-aw v0.82.12, several issue mutation handlers silently discard optional issue intent metadata when issue-intent frontmatter is omitted, even though that metadata is presented to and may be supplied by the agent.
The default behavior is inconsistent across handlers:
set_issue_type.cjs gates the intent path on config.issue_intent === true (line 184). Omitted frontmatter produces {}, so execution falls back to the legacy REST path around lines 286-310.set_issue_field.cjs uses the same opt-in gate (line 167). Rationale, confidence, and suggest metadata is attached only when enabled around lines 341-345.add_labels.cjs also requires config.issue_intent === true (line 47). Rich per-label intent objects are reduced to label names and their metadata is discarded around lines 191-195.close_issue.cjs instead defaults intent handling on with config.issue_intent !== false (line 195) and forwards normalized metadata around lines 282-288.assign_to_agent.cjs likewise uses config.issue_intent !== false (line 68) and normalizes metadata by default around lines 184-185.
The compiler rejects issue-intent frontmatter for add-labels, set-issue-type, and set-issue-field, so valid workflow syntax cannot opt these handlers into the metadata-preserving path.
A real workflow run confirmed the impact: the agent supplied rationale and confidence to set_issue_type, but the handler selected the REST path and discarded both values.
Specification
- Omitted frontmatter must preserve and forward optional issue intent metadata for
set_issue_type, set_issue_field, and add_labels by default, consistently with close_issue and assign_to_agent semantics (config.issue_intent !== false), unless an existing repository convention supports a better unified implementation.
- Explicit disable behavior must remain available wherever it is supported.
add_labels must expose and accept per-label intent objects by default, while remaining compatible with plain label-name strings.- Compiler, schema, generated tool definitions, and runtime behavior must agree: valid agent-supplied intent metadata must not be silently discarded, and supported behavior must not depend on compiler-invalid frontmatter.
- Existing workflows that supply only legacy/plain values must continue to work without modification.
Acceptance criteria
- With configuration omitted,
set_issue_type selects the GraphQL/intent-aware path and forwards supplied rationale and confidence.
- With configuration omitted,
set_issue_field forwards supported rationale, confidence, and suggest metadata.
- With configuration omitted,
add_labels accepts and forwards per-label intent objects without reducing them to names before the intent-aware operation.
- Plain string label names remain accepted and behave compatibly.
- With
issue_intent: true explicitly enabled, plain-string label names are rejected and intent metadata is required for every supported issue mutation.
- An explicit disable selects the legacy/non-intent behavior wherever disabling is supported.
- Focused tests cover omitted configuration, explicit disable, metadata normalization/forwarding, GraphQL/intent path selection, and plain-string compatibility.
- Compiler/schema/runtime tests demonstrate that all supported behavior is reachable through valid workflow syntax and that no valid agent-supplied intent metadata is silently discarded.
Rationale
Optional rationale, confidence, and related intent metadata is currently presented to the agent, but inconsistent default gates silently discard it in three handlers. Default-on behavior aligns these handlers with close_issue and assign_to_agent, preserves useful audit context, and removes a behavior gap that users cannot repair through valid frontmatter.
Confidence
High. The behavior is confirmed by the exact source gates in gh-aw v0.82.12, compiler rejection of the relevant frontmatter, and observed runtime logs showing agent-supplied rationale and confidence being discarded by the REST fallback.
Problem
In gh-aw v0.82.12, several issue mutation handlers silently discard optional issue intent metadata when
issue-intentfrontmatter is omitted, even though that metadata is presented to and may be supplied by the agent.The default behavior is inconsistent across handlers:
set_issue_type.cjsgates the intent path onconfig.issue_intent === true(line 184). Omitted frontmatter produces{}, so execution falls back to the legacy REST path around lines 286-310.set_issue_field.cjsuses the same opt-in gate (line 167). Rationale, confidence, and suggest metadata is attached only when enabled around lines 341-345.add_labels.cjsalso requiresconfig.issue_intent === true(line 47). Rich per-label intent objects are reduced to label names and their metadata is discarded around lines 191-195.close_issue.cjsinstead defaults intent handling on withconfig.issue_intent !== false(line 195) and forwards normalized metadata around lines 282-288.assign_to_agent.cjslikewise usesconfig.issue_intent !== false(line 68) and normalizes metadata by default around lines 184-185.The compiler rejects
issue-intentfrontmatter foradd-labels,set-issue-type, andset-issue-field, so valid workflow syntax cannot opt these handlers into the metadata-preserving path.A real workflow run confirmed the impact: the agent supplied rationale and confidence to
set_issue_type, but the handler selected the REST path and discarded both values.Specification
set_issue_type,set_issue_field, andadd_labelsby default, consistently withclose_issueandassign_to_agentsemantics (config.issue_intent !== false), unless an existing repository convention supports a better unified implementation.add_labelsmust expose and accept per-label intent objects by default, while remaining compatible with plain label-name strings.Acceptance criteria
set_issue_typeselects the GraphQL/intent-aware path and forwards supplied rationale and confidence.set_issue_fieldforwards supported rationale, confidence, and suggest metadata.add_labelsaccepts and forwards per-label intent objects without reducing them to names before the intent-aware operation.issue_intent: trueexplicitly enabled, plain-string label names are rejected and intent metadata is required for every supported issue mutation.Rationale
Optional rationale, confidence, and related intent metadata is currently presented to the agent, but inconsistent default gates silently discard it in three handlers. Default-on behavior aligns these handlers with
close_issueandassign_to_agent, preserves useful audit context, and removes a behavior gap that users cannot repair through valid frontmatter.Confidence
High. The behavior is confirmed by the exact source gates in gh-aw v0.82.12, compiler rejection of the relevant frontmatter, and observed runtime logs showing agent-supplied rationale and confidence being discarded by the REST fallback.