[docs] Self-healing documentation fixes from issue analysis - 2026-03-19

[github-actions]

Self-Healing Documentation Fixes

This PR was automatically created by the Daily Documentation Healer workflow.

Gaps Fixed

• label_command.remove_label field — The remove_label boolean field (added in Add remove_label field to label_command to disable automatic label removal #21751) was missing from documentation. When false, the matched label is not removed after workflow activation, allowing it to function as a persistent state marker rather than a one-shot command. Updated docs/src/content/docs/reference/triggers.md and docs/src/content/docs/patterns/label-ops.md.

Root Cause

DDUw scans merged PRs from the last 24 hours and checks for documentation gaps. The remove_label field was added in commit 6b25513 (PR #21751, merged 2026-03-13). DDUw's daily runs from that window did not document this new field — likely because it was treated as an internal implementation detail (the commit also included unrelated dependency upgrades and test fixes), making it easy to overlook when filtering for user-facing changes.

💡 DDUw Improvement Suggestions

DDUw Improvement Suggestions

Specific gap: DDUw's Step 2 "Analyze Changes" instructs the agent to focus on "Features Added: New functionality, commands, options, tools, or capabilities." A new field on an existing trigger object (label_command.remove_label) can be missed because it looks like an internal detail (a boolean flag inside a complex commit) rather than a standalone feature.

Suggested improvement: Add a heuristic in DDUw's Step 2 to scan for new fields in frontmatter_extraction_yaml.go and compiler_*.go that affect trigger or safe-outputs behavior — these are user-facing configuration options even when bundled in larger refactoring commits. Specifically, when reviewing commits that touch pkg/workflow/compiler_activation_job.go, pkg/workflow/frontmatter_extraction_yaml.go, or schema files, check for new field names in the code that are not yet present in docs/src/content/docs/reference/triggers.md, docs/src/content/docs/patterns/, or docs/src/content/docs/reference/frontmatter-full.md.

Related Issues

• Addresses gap identified from closed issues [cli-consistency] CLI Consistency Issues - 2026-03-17 #21399, [cli-consistency] CLI Consistency Issues - 2026-03-16 #21239 (CLI Consistency reports noting documentation sync issues)
• Code feature from PR Add remove_label field to label_command to disable automatic label removal #21751

References:

• §23312809989

Note

🔒 Integrity filtering filtered 5 items

Integrity filtering activated and filtered the following items during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• #20663 (search_issues: Resource 'issue:The dependencies: documentation undersells APM and lacks guidance for users #20663' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
• #20646 (search_issues: Resource 'issue:invalid html anchor used in error message: CONTRIBUTING.md#prerequisites and missing description of necessary tools #20646' has lower integrity than agent requires. Agent would need to drop integrity tags [approved:all] to trust this resource.)
• issue:[instructions] Sync github-agentic-workflows.md with v0.40.1 #21138 (issue_read: Resource 'issue:[instructions] Sync github-agentic-workflows.md with v0.40.1 #21138' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
• issue:GHES: Create prerequisites guide and troubleshooting runbook for Copilot engine #20968 (issue_read: Resource 'issue:GHES: Create prerequisites guide and troubleshooting runbook for Copilot engine #20968' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)
• issue:[cli-consistency] CLI Consistency Issues - 2026-03-17 #21399 (issue_read: Resource 'issue:[cli-consistency] CLI Consistency Issues - 2026-03-17 #21399' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)

Generated by Daily Documentation Healer · ◷

• expires on Mar 22, 2026, 7:31 PM UTC

[Copilot]

Pull request overview

Adds missing documentation for the label_command.remove_label field so users can disable automatic label removal and use labels as persistent state markers.

Changes:

• Added remove_label: false examples for label_command in both reference and patterns docs.
• Documented default/behavior of remove_label and its impact on label-removal behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
docs/src/content/docs/reference/triggers.md	Documents remove_label in the trigger reference with an example and behavioral notes.
docs/src/content/docs/patterns/label-ops.md	Adds a LabelOps pattern example and explanation for keeping labels after activation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The surrounding description implies the activation job always injects a label-removal step and that label removal is associated with pull-requests: write. In the implementation, label removal is conditional (remove_label: false swaps the removal step for get_trigger_label.cjs), and PR label removal uses the Issues API (so it’s governed by issues: write), while discussions use discussions: write. Suggest updating this paragraph to reflect the conditional step and to reference the correct permissions (issues: write for issues/pull_request; discussions: write for discussion) that are avoided when remove_label: false.

Suggested change

	The compiler generates `issues`, `pull_request`, and/or `discussion` events with `types: [labeled]`, adds a `workflow_dispatch` trigger with `item_number` for manual testing, and injects a label removal step in the activation job. The matched label name is exposed as `needs.activation.outputs.label_command`.
	The `remove_label` field (boolean, default `true`) controls whether the label is automatically removed after activation. Set to `false` to keep the label on the item — useful when the label represents persistent state rather than a one-shot command. When `remove_label: false`, the workflow does not need `issues: write` or `pull-requests: write` permissions for label removal.
	The compiler generates `issues`, `pull_request`, and/or `discussion` events with `types: [labeled]`, adds a `workflow_dispatch` trigger with `item_number` for manual testing, and, when `remove_label` is `true` (the default), injects a label removal step in the activation job. The matched label name is exposed as `needs.activation.outputs.label_command`.
	The `remove_label` field (boolean, default `true`) controls whether the label is automatically removed after activation. Set to `false` to keep the label on the item — useful when the label represents persistent state rather than a one-shot command. When `remove_label: false`, the workflow does not perform label removal, so it does not require additional write permissions for label changes (avoiding `issues: write` for issues/pull_request items and `discussions: write` for discussions).

[Copilot]

This sentence references pull-requests: write as the relevant permission for label removal. In the current implementation, label removal for pull requests uses the Issues REST API (so it’s issues: write), and discussion label removal uses discussions: write; pull-requests: write is not required for label removal. Recommend updating this line (and the later NOTE in this doc about permissions for automatic label removal) to reflect the actual permissions avoided when remove_label: false.

Suggested change

The `remove_label` field (boolean, default `true`) controls whether the matched label is removed after the workflow activates. Set it to `false` when the label represents a persistent state rather than a transient command — for example, to mark that an item is currently being processed without consuming the label. When `remove_label: false`, the `issues: write` / `pull-requests: write` permissions for label removal are not required.

The `remove_label` field (boolean, default `true`) controls whether the matched label is removed after the workflow activates. Set it to `false` when the label represents a persistent state rather than a transient command — for example, to mark that an item is currently being processed without consuming the label. When `remove_label: false`, the `issues: write` (for issues and pull requests) and `discussions: write` permissions used for label removal are not required.