feat(triage): generalize workflow-change block into block_auto_promotion by rh-hemartin · Pull Request #1078 · fullsend-ai/agents

rh-hemartin · 2026-08-28T11:43:50Z

Summary

Replace the single-purpose requires_workflow_changes boolean with a general-purpose block_auto_promotion object (blocked + reason). Workflow-file detection now uses that field so later gates (effort scoring) can reuse the same post-script path and attach a reason.

This is the first of two slices split from feat/2207-effort-gating. Effort estimation is not in this PR.

The prompt's second block condition ("any other condition where auto-dispatch would be premature") is deliberately provisioned ahead of the effort-scoring gate (fullsend#2207 / follow-up PR) so reviewers and agents do not need to guess the intent. This PR only implements the workflow-file gate; the second clause is the hook for that follow-up.

Ref fullsend-ai/fullsend#2207

Behavior

When blocked is true, the post-script appends **Auto-promotion blocked:** <reason> to the triage comment for every category.
For bug/documentation/performance, blocked=true also applies triaged instead of ready-to-code. Categories that already go to triaged (feature, security, other) keep that label.
requires_workflow_changes is removed; the schema and post-script only accept block_auto_promotion.
The reason is flattened for the comment (newlines become spaces; ANSI is stripped) so :: and % stay intact. A held-for-review footer is used whenever blocked is true, including feature and TRIAGE_AUTO_CODE=off.

Test plan

bash scripts/post-triage-test.sh
bash scripts/validate-output-schema-test.sh

qodo-code-review · 2026-08-28T11:44:44Z

PR Summary by Qodo

Generalize triage auto-promotion blocking with reasons

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Replaces the workflow-specific flag with reusable, reasoned auto-promotion blocking.
• Preserves legacy outputs while routing blocked auto-code categories to human review.
• Sanitizes triage comments and expands schema and post-script regression coverage.

Diagram

graph TD
  A["Triage agent"] --> B["Result schema"] --> C["Post-triage script"] --> D{"Auto-code eligible?"}
  D -->|Yes| E{"Promotion blocked?"}
  D -->|No| G["Triaged"]
  E -->|No| F["Ready to code"]
  E -->|Yes| G
  E -.->|Reason| H["Held comment"]

High-Level Assessment

The following are alternative approaches to this PR:

1. List independent blockers

➕ Represents multiple simultaneous gates without merging reasons
➕ Allows future gates to add structured blocker types
➖ Expands the schema and prompt contract prematurely
➖ Requires aggregation and compatibility logic in the post-script

2. Keep gate-specific fields

➕ Makes each blocking condition explicit
➕ Minimizes change to the existing workflow-specific path
➖ Duplicates routing logic as new gates arrive
➖ Couples post-processing to every new triage policy

Recommendation: Use the PR's single generalized block object for this slice: it centralizes routing, carries a human-readable reason, and preserves one-release compatibility without over-designing future effort gating. Consider a blocker array only if multiple independent producers must report concurrent reasons.

Files changed (9) +364 / -82

Enhancement (3) +179 / -50

triage.mdTeach triage to emit reasoned promotion blocks +13/-4

Teach triage to emit reasoned promotion blocks

• Updates workflow-change detection and output examples to use block_auto_promotion. Clarifies category routing and instructs the agent to avoid fenced code blocks in comments.

agents/triage.md

post-triage.shBundle generalized auto-promotion gate behavior +83/-23

Bundle generalized auto-promotion gate behavior

• Updates the generated post-triage script to resolve the new gate with legacy fallback, route eligible blocked issues to triaged, sanitize untrusted text, and publish held-review guidance.

scripts/post-triage.sh

post-triage.src.shImplement generalized auto-promotion gating +83/-23

Implement generalized auto-promotion gating

• Introduces the source implementation for reasoned blocking, backward-compatible workflow handling, comment fence removal, label routing, and blocked-specific next steps.

scripts/post-triage.src.sh

Tests (2) +149 / -25

post-triage-test.shCover blocked routing and comment sanitization +115/-25

Cover blocked routing and comment sanitization
• Expands regression coverage for category routing, legacy fallback, reason footers, held-review guidance, workflow-command sanitization, and fenced-block removal.
scripts/post-triage-test.sh

validate-output-schema-test.shValidate the new promotion block schema +34/-0

Validate the new promotion block schema
• Adds valid and invalid cases for required fields, empty reasons, extra properties, omission behavior, and deprecated-field compatibility.
scripts/validate-output-schema-test.sh

Documentation (3) +22 / -6

FEATURES.mdUpdate feature guidance for generalized promotion blocks +1/-1

Update feature guidance for generalized promotion blocks
• Replaces the workflow-specific schema example with the reusable block_auto_promotion field.
FEATURES.md

code.mdClarify ready-to-code promotion behavior +1/-1

Clarify ready-to-code promotion behavior
• Documents that the triage post-script applies ready-to-code only when auto-promotion is not blocked.
docs/code.md

triage.mdDocument auto-promotion blocking and compatibility +20/-4

Document auto-promotion blocking and compatibility
• Explains blocked and unblocked outcomes, affected categories, reason handling, and the temporary requires_workflow_changes fallback.
docs/triage.md

Other (1) +14 / -1

triage-result.schema.jsonAdd the block_auto_promotion result contract +14/-1

Add the block_auto_promotion result contract
• Adds a strict blocked-and-reason object with reason length validation. Retains requires_workflow_changes as an optional deprecated property for one release.
schemas/triage-result.schema.json

fullsend-ai-review · 2026-08-28T11:45:35Z

🤖 Finished Review · ✅ Success · Started 11:45 AM UTC · Completed 12:06 PM UTC

Commit: fa3c916 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $9.18

qodo-code-review · 2026-08-28T11:49:02Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (2)

1. triage.md adds agent directives 📜 Skill insight ⛨ Security

Description

The changed prompt text directly instructs the triage agent to set and apply block_auto_promotion.
This introduces agent-instruction patterns in a changed configuration/prompt file, which the
checklist expressly prohibits.

Code

agents/triage.md[R383-385]

+**Blocking auto-promotion:** Use the `block_auto_promotion` field in `triage_summary` to prevent the post-triage script from auto-promoting the issue to the code agent. Set `blocked: true` with a `reason` when:
+- The fix requires modifying CI/pipeline configuration files (`.github/workflows/`, `.gitlab-ci.yml`, `.fullsend/.github/workflows/`, or enrolled-repo shim workflows) that the code agent cannot modify under current permissions.
+- Any other condition where auto-dispatch would be premature.

Relevance

●●● Strong
Prompt-instruction compliance findings are accepted when changed agent guidance contains imperative
directives.
PR-#381
PR-#326

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1538322 prohibits agent-instruction patterns in changed comments, string literals,
or configuration values. The added text uses imperative directives such as `Use the
block_auto_promotion field and Set blocked: true`, directly matching the prohibited pattern.

agents/triage.md[383-389]
Skill: code-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The changed `agents/triage.md` content contains direct agent instructions, contrary to PR Compliance ID 1538322.

## Issue Context
The added text directs the agent to use `block_auto_promotion` and specifies when to set it. Rework the change so prohibited instruction patterns are not introduced in comments, strings, or configuration values.

## Fix Focus Areas
- agents/triage.md[383-389]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. False block still falls back 🐞 Bug ≡ Correctness

Description

Using jq's // empty turns an explicit block_auto_promotion.blocked: false into an empty result,
so a simultaneously present deprecated requires_workflow_changes: true incorrectly blocks
promotion. This violates the documented rule that the deprecated field is consulted only when
block_auto_promotion is absent.

Code

scripts/post-triage.src.sh[R424-426]

+    BLOCKED=$(jq -r '.triage_summary.block_auto_promotion.blocked // empty' "${RESULT_FILE}")
+    BLOCK_REASON=$(jq -r '.triage_summary.block_auto_promotion.reason // empty' "${RESULT_FILE}")
+    if [[ -z "${BLOCKED}" ]]; then

Relevance

●●● Strong
This is a deterministic jq false-value fallback bug, matching accepted requests for robust
null/boolean handling.
PR-#284
PR-#876

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The schema allows both fields and allows blocked to be false, while the documentation limits
legacy fallback to absence of the new object. In jq, false // empty emits no value, so the
subsequent empty check enters the legacy fallback and changes the result to true.

scripts/post-triage.src.sh[424-435]
schemas/triage-result.schema.json[200-212]
docs/triage.md[150-157]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
An explicit `block_auto_promotion.blocked: false` is lost because jq's `//` treats `false` like a missing value, allowing the deprecated flag to override it.

## Issue Context
The schema permits both migration fields, while the documented precedence says `requires_workflow_changes` applies only when the new object is absent. Test the valid combination `blocked:false` plus `requires_workflow_changes:true`.

## Fix Focus Areas
- scripts/post-triage.src.sh[424-436]
- scripts/post-triage-test.sh[810-818]
- scripts/post-triage.sh[1349-1361]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Protected automation paths modified 📜 Skill insight § Compliance

Description

This PR modifies protected agents/ and scripts/ paths, including triage instructions and
executable automation. These governance/automation changes require human approval and must not be
auto-approved.

Code

scripts/post-triage.src.sh[R73-76]

+# Drop paired line-start fenced code blocks. An unmatched opener is left
+# in place so the remainder of the text is not deleted. Inline triple
+# backticks (not at line start) are left unchanged.
+strip_line_start_fences() {

Relevance

●● Moderate
Protected-path approval findings are mixed: some governance requests were rejected, while others
remain undetermined.
PR-#609
PR-#476
PR-#157

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1538392 mandates a finding whenever protected paths such as agents/ or scripts/
are modified. The diff adds executable processing logic under scripts/ and also changes
agents/triage.md, so the protected-path review requirement is triggered.

scripts/post-triage.src.sh[73-76]
agents/triage.md[133-133]
Skill: pr-review

4. Fence stripping is bypassable 🐞 Bug ≡ Correctness

Description

The sanitizer recognizes every line beginning with exactly three backticks as a delimiter, so valid
tilde-fenced blocks are left intact and backtick-prefixed content inside a longer/matching fence can
be mistaken for its close. Consequently the post-script can publish code content it claims to strip,
or delete the wrong region of the triage comment.

Code

scripts/post-triage.src.sh[R80-87]

+      if ($0 ~ /^```/) {
+        n++
+        pos[n] = NR
+      }
+    }
+    END {
+      for (i = 1; i + 1 <= n; i += 2) {
+        for (j = pos[i]; j <= pos[i + 1]; j++) skip[j] = 1

Relevance

●●● Strong
Fence parsing edge cases are accepted; historical linter fixes specifically broaden fence
recognition and handling.
PR-#476

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The agent contract prohibits fenced code blocks generally, but the implementation records only lines
matching ^``` and blindly removes alternating pairs. The same helper's output becomes the posted
comment, so unsupported or prematurely closed fences reach every tracker.

agents/triage.md[367-372]
scripts/post-triage.src.sh[76-97]
scripts/post-triage.src.sh[489-495]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new sanitizer only detects `^```` and pairs matches by position rather than matching actual Markdown opening and closing delimiters. Valid fenced blocks can survive, and delimiter-like lines inside a block can terminate removal early.

## Issue Context
Track the opening delimiter character and length, accept both backtick and tilde fences, and only close on a compatible delimiter-only line. Add tests for tilde fences, longer backtick fences containing triple backticks, and non-closing backtick-prefixed lines.

## Fix Focus Areas
- scripts/post-triage.src.sh[76-97]
- scripts/post-triage-test.sh[608-618]
- scripts/post-triage.sh[1001-1022]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Context sources

✅ Compliance rules (platform): 56 rules

✅ Skills: 4 invoked

code-review

code-implementation

pr-review

docs-review

Review mode: ⚖️ Balanced

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

fullsend-ai-review · 2026-08-28T12:06:35Z