agentic-devtools 0.2.164__tar.gz → 0.2.165__tar.gz

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agentic-devtools
-Version: 0.2.164
+Version: 0.2.165
 Summary: Agentic devtools integrate Jira, DevOps & more
 Author: ayaiayorg
 License-Expression: MIT

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/agentic_devtools/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.2.164'
-__version_tuple__ = version_tuple = (0, 2, 164)
+__version__ = version = '0.2.165'
+__version_tuple__ = version_tuple = (0, 2, 165)
 
 __commit_id__ = commit_id = None

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/agentic_devtools/cli/ci/pipeline/actions/dispatch_repair.py

@@ -104,10 +104,9 @@ class DispatchRepairAction:
                         snapshot.pr_number,
                         snapshot.copilot_review_id,
                     )
-                    derived.set("repair_dispatched", True)
                     return ActionResult(
                         name=self.name,
-                        decision=ActionDecision.EXECUTE,
+                        decision=ActionDecision.SKIP,
                         details=f"Repair already dispatched for review_id={snapshot.copilot_review_id}",
                     )
             except Exception as exc:

agentic_devtools-0.2.165/specs/1759-bug-automatic-assignment-issues/checklists/requirements.md

@@ -0,0 +1,50 @@
+# Specification Quality Checklist: Fix Agent Assignment Token in speckit-implement-trigger Workflow
+
+**Purpose**: Validate specification completeness before proceeding to planning
+**Created**: 2026-06-03
+**Feature**: [spec.md](../spec.md)
+**Source Issue**: #1759
+
+## Content Quality
+
+- [ ] CHK001 All three user stories (Automatic Agent Assignment, Loud Failure on Missing Token, Assignment Identity Logging) clearly articulate user value in terms of pipeline reliability and operator
+  experience rather than implementation mechanics
+- [ ] CHK002 User stories follow "As a [role], I need [capability], so that [benefit]" format — verify US1 (repository maintainer), US2 (DevOps engineer), and US3 (pipeline operator) each have
+  distinct roles and benefits
+- [ ] CHK003 Priority assignments (P1 for core bug fix, P2 for observability, P3 for logging) are justified with explicit rationale in "Why this priority" sections and reflect correct dependency
+  ordering
+- [ ] CHK004 Requirements FR-001 through FR-007 specify WHAT behavior is needed without prescribing internal code structure (verify no variable names, loop constructs, or algorithm choices leak into
+  requirements beyond the necessary `github-token` input mechanism)
+
+## Requirement Completeness
+
+- [ ] CHK005 Each acceptance scenario in US1 (token selection, fallback, assignment confirmation, response validation) and US2 (missing token, single token) is independently testable without requiring
+  other scenarios to pass first
+- [ ] CHK006 Edge cases document all failure modes: non-2xx responses, 404 race condition, expired/revoked token (401), unrecognized `agent_assignment` field, and downstream step failures after
+  assignment — verify each has a defined expected behavior
+- [ ] CHK007 Acceptance scenarios follow Given/When/Then format with specific observable outcomes (HTTP status codes, output variable values, annotation formats) rather than vague success conditions
+- [ ] CHK008 Success criteria SC-001 through SC-005 include specific numeric thresholds: 100% assignment success over 10 runs, failure within 5 seconds, exactly one log line, zero silent failures over
+  14 days, ≤3 second execution time increase
+- [ ] CHK009 Scope boundaries are explicitly stated: change confined to `speckit-implement-trigger.yml` (NFR-004), permissions block unchanged, follow-up GET verification explicitly deferred as out of
+  scope
+- [ ] CHK010 Dependencies on external entities are documented: `SPECKIT_PR_TOKEN` and `COPILOT_GITHUB_TOKEN` secrets must exist in target repositories, `actions/github-script@v7` `github-token` input
+  mechanism, and the GitHub Issues PATCH API `agent_assignment` field behavior
+
+## Feature Readiness
+
+- [ ] CHK011 FR-001 (elevated token pattern), FR-002 (preflight step), FR-004 (response validation), and FR-007 (downstream steps) each have corresponding acceptance scenarios that verify their
+  behavior — confirm no functional requirement lacks a testable scenario
+- [ ] CHK012 User scenarios cover the full operational lifecycle: successful assignment (US1), new repository onboarding failure (US2), and post-incident investigation (US3) — verify no critical
+  operator workflow is unaddressed
+- [ ] CHK013 Success criteria SC-001 (assignment success rate), SC-002 (failure detection speed), SC-003 (logging presence), SC-004 (zero silent failures window), and SC-005 (performance budget) each
+  define a measurable metric with a specific measurement method or observation period
+- [ ] CHK014 Clarification answers confirm implementation boundaries (separate `- name:` block for preflight, `github-token` input not env var, response body validation sufficient without GET
+  follow-up) without the requirements themselves dictating code-level decisions beyond the workflow YAML structure
+
+## Notes
+
+- This checklist was generated from the specification content for issue #1759
+- Items marked incomplete require spec updates before proceeding to planning
+
+---
+*Generated by Copilot SDK (claude-opus-4.6)*

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/specs/1759-bug-automatic-assignment-issues/spec.md

@@ -1,22 +1,53 @@
 # Feature Specification: Fix Agent Assignment Token in speckit-implement-trigger Workflow
 
-**Feature Branch**: `speckit/1759/phase-1-specify`  
+**Feature Branch**: `speckit/1759/phase-2-clarify`  
 **Created**: 2026-06-03  
 **Status**: Draft  
 **Input**: GitHub Issue #1759 — silent failure of Copilot coding agent assignment after phase 5 spec PR merge  
 **Source Issue**: #1759 (<https://github.com/ayaiayorg/agentic-devtools/issues/1759>)
 
+## Clarifications
+
+### Session 2026-06-03
+
+- Q: FR-007 states the "Update Labels" step must also use the elevated token, but should the "Post Implementation Triggered Comment" step (line 455+) that also follows the assignment step
+  also be updated to use the same elevated token pattern? → A: Yes. All steps in the job that follow the agent assignment step — including "Update Labels" and "Post Implementation Triggered
+  Comment" — must use the elevated token pattern (`SPECKIT_PR_TOKEN || COPILOT_GITHUB_TOKEN`) since they operate on the same issue and the `GITHUB_TOKEN` permissions may be insufficient for
+  label mutation or commenting in forked-repo scenarios. FR-007 is expanded to cover both steps.
+
+- Q: Should the preflight check be a separate workflow step (its own `- name:` block) or inline logic at the top of the existing `actions/github-script` step? → A: It must be a separate workflow step
+  with its own `- name:` block (e.g., `"Validate Agent Assignment Token"`). This keeps concerns separated, makes the failure point unambiguous in the GitHub Actions UI, and allows the assignment
+  step's `if:` condition to depend on the preflight step's outcome.
+
+- Q: How should the step verify that the `agent_assignment` was actually applied (FR-004 / edge case about API ignoring the field)? Specifically, should it perform a follow-up GET request to confirm
+  assignment, or is validating the PATCH response body sufficient? → A: Validating the PATCH response body is sufficient for the initial fix. The step must check that the response status is 200 and
+  that the response body contains a non-null `agent_assignment` field. If the response is 200 but `agent_assignment` is null or absent in the response, the step must emit a `::warning::` annotation
+  indicating the assignment may not have taken effect and set `assigned` output to `'false'`. A follow-up GET verification can be added as a future enhancement but is out of scope for this fix.
+
+- Q: The spec references the `github-token` input of `actions/github-script@v7` — should the token be passed via the `github-token` input (which replaces the octokit instance's auth) or via
+  an environment variable used inside the script? → A: The token must be passed via the `github-token` input of `actions/github-script@v7`, exactly as done in `speckit-phase-progression.yml`
+  (line 552 pattern: `GH_TOKEN: ${{ secrets.SPECKIT_PR_TOKEN || secrets.COPILOT_GITHUB_TOKEN }}`). However, since `actions/github-script` uses `github-token` (not `GH_TOKEN` env var) to
+  authenticate the `github` octokit instance, the correct pattern is: `github-token: ${{ secrets.SPECKIT_PR_TOKEN || secrets.COPILOT_GITHUB_TOKEN }}` in the `with:` block.
+
+- Q: NFR-004 constrains the change to the single workflow file, but what if the `permissions` block (currently `issues: write`, `contents: read`, `pull-requests: read`) needs adjustment for the
+  PAT-based approach? → A: The `permissions` block does not need adjustment. When a PAT is passed via `github-token`, the PAT's own scopes determine authorization — the workflow `permissions` block
+  only constrains the default `GITHUB_TOKEN`. Since the fix explicitly avoids using `GITHUB_TOKEN`, the existing permissions block is irrelevant to the agent assignment step and should remain
+  unchanged to avoid unintended side effects.
+
 ## Problem Statement
 
 The speckit pipeline is designed as a fully automated specification-to-implementation conveyor: once a phase 5 specification PR merges, the `speckit:needs-implementation` label is applied, triggering
 `speckit-implement-trigger.yml` to automatically assign the Copilot coding agent to the originating issue. This automation is a critical link in the pipeline — without it, issues that have completed
 the specification phase stall indefinitely, requiring manual intervention from a maintainer to kick off the implementation phase.
 
-Currently, the "Assign Copilot Coding Agent" step in `speckit-implement-trigger.yml` (lines 381–410) uses `actions/github-script@v7` without specifying a `github-token` input. This causes the step to
-authenticate with the default `GITHUB_TOKEN` provided by GitHub Actions. The `GITHUB_TOKEN` is a GitHub Actions–issued, job-scoped token whose permissions are limited to the explicit `permissions` block
-declared in the workflow. While the workflow declares `issues: write`, the agent assignment API (`PATCH /repos/{owner}/{repo}/issues/{issue_number}` with an `agent_assignment` payload) requires
-elevated permissions that are only available through a Personal Access Token (PAT) with broader repository and Copilot scopes. The observed symptom is that assignment does not take effect even when the
-workflow appears to complete successfully. One plausible failure mode is a 2xx response where the API ignores `agent_assignment` rather than applying it, which this fix must make observable and validate.
+Currently, the "Assign Copilot Coding Agent" step in `speckit-implement-trigger.yml` (lines 381–410) uses `actions/github-script@v7`
+without specifying a `github-token` input. This causes the step to authenticate with the default `GITHUB_TOKEN` provided by GitHub
+Actions. The `GITHUB_TOKEN` is a GitHub Actions–issued, job-scoped token whose permissions are limited to the explicit `permissions`
+block declared in the workflow. While the workflow declares `issues: write`, the agent assignment API (`PATCH /repos/{owner}/{repo}/issues/{issue_number}`
+with an `agent_assignment` payload) requires elevated permissions that are only available through a Personal Access Token (PAT) with
+broader repository and Copilot scopes. The observed symptom is that assignment does not take effect even when the workflow appears to
+complete successfully. One plausible failure mode is a 2xx response where the API ignores `agent_assignment` rather than applying it,
+which this fix must make observable and validate.
 
 The consequence is significant: every feature that completes the specification pipeline (phases 1 through 5) becomes stranded. The `speckit:needs-implementation` label is applied, the workflow runs,
 but the actual Copilot agent assignment never takes effect. A maintainer must then manually discover the stalled issue and trigger implementation, defeating the purpose of the automated pipeline. This
@@ -44,7 +75,8 @@ configured model (default `claude-opus-4.6`).
 **Acceptance Scenarios**:
 
 1. **Given** a repository with `SPECKIT_PR_TOKEN` configured and a phase 5 spec PR that has been approved, **When** the PR merges and `speckit:needs-implementation` is applied to the issue, **Then**
-   the `speckit-implement-trigger.yml` workflow assigns the Copilot coding agent to the issue using `SPECKIT_PR_TOKEN` and the step completes with exit code 0.
+   the `speckit-implement-trigger.yml` workflow assigns the Copilot coding agent to the issue using `SPECKIT_PR_TOKEN` via the `github-token` input of `actions/github-script@v7` and the step completes
+   with exit code 0.
 
 2. **Given** a repository where `SPECKIT_PR_TOKEN` is not configured but `COPILOT_GITHUB_TOKEN` is, **When** the implementation trigger workflow runs, **Then** the agent assignment step falls back to
    `COPILOT_GITHUB_TOKEN` and the assignment succeeds.
@@ -52,6 +84,13 @@ configured model (default `claude-opus-4.6`).
 3. **Given** a repository with both tokens configured and a valid issue number, **When** the agent assignment step executes, **Then** the issue shows the Copilot coding agent assigned with
    `custom_agent: 'speckit.implement'` and the model matching the `COPILOT_MODEL` environment variable.
 
+4. **Given** a successful agent assignment where the API returns HTTP 200, **When** the response body contains a non-null `agent_assignment` field, **Then** the step sets `assigned` output to
+   `'true'`. **When** the response body contains a null or absent `agent_assignment` field despite HTTP 200, **Then** the step emits a `::warning::` annotation indicating the assignment may not have
+   taken effect and sets `assigned` output to `'false'`.
+
+5. **Given** the `trigger-implementation` job in `.github/workflows/speckit-implement-trigger.yml`, **When** the workflow YAML is inspected after the fix, **Then** the `Update Labels` step and
+   `Post Implementation Triggered Comment` step each explicitly set `github-token: ${{ secrets.SPECKIT_PR_TOKEN || secrets.COPILOT_GITHUB_TOKEN }}`.
+
 ---
 
 ### User Story 2 - Loud Failure on Missing Token (Priority: P2)
@@ -59,9 +98,10 @@ configured model (default `claude-opus-4.6`).
 As a DevOps engineer configuring the speckit pipeline for a new repository, I need the workflow to fail loudly and with a clear error message if neither `SPECKIT_PR_TOKEN` nor `COPILOT_GITHUB_TOKEN`
 is configured, so that I can diagnose setup problems immediately rather than debugging silent failures after deployment.
 
-Currently, if no appropriate PAT is available, the step falls through to `GITHUB_TOKEN`, which lacks the required permissions for agent assignment. The observed behavior is that the workflow can appear
-successful while assignment does not take effect; one plausible explanation is a 2xx response that ignores `agent_assignment`. The fix adds a preflight check that validates token availability
-before attempting the assignment, producing an actionable error message that names the required secrets.
+Currently, if no appropriate PAT is available, the step falls through to `GITHUB_TOKEN`, which lacks the required permissions for
+agent assignment. The observed behavior is that the workflow can appear successful while assignment does not take effect; one plausible
+explanation is a 2xx response that ignores `agent_assignment`. The fix adds a dedicated preflight validation step that checks token
+availability before attempting the assignment, producing an actionable error message that names the required secrets.
 
 **Why this priority**: Observability is second only to correctness. A clear error on misconfiguration prevents hours of debugging and ensures new repository onboarding surfaces problems at setup time,
 not during the first real pipeline run.
@@ -71,8 +111,9 @@ explicit error annotation naming the missing secrets.
 
 **Acceptance Scenarios**:
 
-1. **Given** a repository where neither `SPECKIT_PR_TOKEN` nor `COPILOT_GITHUB_TOKEN` is configured, **When** the implementation trigger workflow reaches the token preflight check, **Then** the step
-   fails with a `::error::` annotation stating that at least one of these secrets must be configured for agent assignment.
+1. **Given** a repository where neither `SPECKIT_PR_TOKEN` nor `COPILOT_GITHUB_TOKEN` is configured, **When** the implementation
+   trigger workflow reaches the token preflight check step, **Then** the step fails with a `::error::` annotation stating that at
+   least one of these secrets must be configured for agent assignment.
 
 2. **Given** a repository where only `SPECKIT_PR_TOKEN` is configured, **When** the preflight check runs, **Then** it passes and logs which token identity will be used (without revealing the token
    value).
@@ -90,8 +131,8 @@ was selected. The logging must mask the actual token value while clearly identif
 **Why this priority**: This is a quality-of-life improvement for operators. It does not affect whether the assignment succeeds but makes troubleshooting faster when issues arise in the future.
 
 **Independent Test**: Can be tested by running the workflow with both tokens configured and
-inspecting the step output for a log line like `"Using token: SPECKIT_PR_TOKEN (primary)"` or
-`"Using token: COPILOT_GITHUB_TOKEN (fallback)"`.
+inspecting the step output for a log line like `"Agent assignment token: SPECKIT_PR_TOKEN (primary)"` or
+`"Agent assignment token: COPILOT_GITHUB_TOKEN (fallback)"`.
 
 **Acceptance Scenarios**:
 
@@ -115,24 +156,33 @@ inspecting the step output for a log line like `"Using token: SPECKIT_PR_TOKEN (
 - What happens when the token has expired or been revoked between the preflight check and the API call? The step must catch the 401 response, log an actionable error (`"Token authentication failed —
   verify token has not expired"`), and fail the step.
 
-- What happens when `agent_assignment` field is not recognized by the API (e.g., API version change)? The step must verify the response contains evidence the assignment was processed (check for
-  non-null `agent_assignment` in the response body or a 200 status) and warn if the field appears to have been ignored.
+- What happens when `agent_assignment` field is not recognized by the API (e.g., API version change)? The step must verify the response contains evidence the assignment was processed: check that the
+  response body contains a non-null `agent_assignment` field when the status is 200. If the field is null or absent despite a 200 status, emit a `::warning::` annotation indicating the assignment may
+  not have taken effect and set `assigned` output to `'false'`.
+
+- What happens when the "Update Labels" or "Post Implementation Triggered Comment" steps fail due to token issues? The "Update Labels" step already uses `try/catch` and logs errors non-fatally, while
+  "Post Implementation Triggered Comment" currently does not wrap `createComment` and may fail that step if the API call errors. With the elevated token, these steps are expected to succeed, and any
+  downstream failure must not mask the success/failure of the primary agent assignment step.
 
 ## Requirements
 
 ### Functional Requirements
 
 - **FR-001**: The "Assign Copilot Coding Agent" step in `speckit-implement-trigger.yml` MUST authenticate using `secrets.SPECKIT_PR_TOKEN` as the primary token, with `secrets.COPILOT_GITHUB_TOKEN` as
-  fallback, via the `github-token` input of `actions/github-script@v7`. The step MUST NOT fall back to the default `GITHUB_TOKEN` under any circumstances.
+  fallback, via the `github-token` input of `actions/github-script@v7`
+  (pattern: `github-token: ${{ secrets.SPECKIT_PR_TOKEN || secrets.COPILOT_GITHUB_TOKEN }}`). The step MUST NOT fall back to the default `GITHUB_TOKEN` under any circumstances.
 
-- **FR-002**: The workflow MUST include a preflight validation step that runs before the agent assignment step and fails the job with a descriptive `::error::` annotation if neither `SPECKIT_PR_TOKEN`
-  nor `COPILOT_GITHUB_TOKEN` is available as a non-empty secret.
+- **FR-002**: The workflow MUST include a dedicated preflight validation step (separate `- name:` block, e.g., `"Validate Agent Assignment Token"`) that runs before the agent assignment step and fails
+  the job with a descriptive `::error::` annotation if neither `SPECKIT_PR_TOKEN`
+  nor `COPILOT_GITHUB_TOKEN` is available as a non-empty secret. This step must be a separate workflow step so that failures are unambiguous in the GitHub Actions UI.
 
-- **FR-003**: The agent assignment step MUST log the identity of the token being used (e.g., `"SPECKIT_PR_TOKEN"` or `"COPILOT_GITHUB_TOKEN"`) without revealing any portion of the token value. This
+- **FR-003**: The agent assignment step MUST log the identity of the token being used (e.g., `"Agent assignment token: SPECKIT_PR_TOKEN (primary)"` or `"Agent assignment token: COPILOT_GITHUB_TOKEN
+  (fallback)"`) without revealing any portion of the token value. This
   log line MUST appear before the API call is made.
 
 - **FR-004**: The agent assignment step MUST treat any non-2xx HTTP response from the `PATCH /repos/{owner}/{repo}/issues/{issue_number}` API as a step failure, except for 404 (issue missing/deleted),
-  which MUST be handled as a non-fatal skip with a clear log message and `assigned` output set to `'false'`.
+  which MUST be handled as a non-fatal skip with a clear log message and `assigned` output set to `'false'`. Additionally, when the response is HTTP 200 but the response body contains a null or absent
+  `agent_assignment` field, the step MUST emit a `::warning::` annotation and set `assigned` output to `'false'`.
 
 - **FR-005**: The agent assignment step MUST preserve all existing assignment parameters unchanged: `custom_agent: 'speckit.implement'`, `base_branch: 'main'`, `custom_instructions` referencing the
   discovered spec directory, and `model` from the `COPILOT_MODEL` environment variable.
@@ -140,9 +190,9 @@ inspecting the step output for a log line like `"Using token: SPECKIT_PR_TOKEN (
 - **FR-006**: The workflow's existing conditional logic (`steps.discover.outputs.found == 'true' && steps.check-pr.outputs.exists != 'true'`) MUST remain unchanged — the fix is limited to
   authentication and observability, not control flow.
 
-- **FR-007**: The "Update Labels" step that follows the assignment MUST also use the same elevated token pattern
-  (`SPECKIT_PR_TOKEN || COPILOT_GITHUB_TOKEN`) if it currently relies on `GITHUB_TOKEN`,
-  to ensure label operations after assignment do not silently fail.
+- **FR-007**: The "Update Labels" step and the "Post Implementation Triggered Comment" step that follow the assignment MUST also use the same elevated token pattern
+  (`github-token: ${{ secrets.SPECKIT_PR_TOKEN || secrets.COPILOT_GITHUB_TOKEN }}`) to ensure label operations and issue comments after assignment do not silently fail due to
+  insufficient `GITHUB_TOKEN` permissions.
 
 ### Non-Functional Requirements
 
@@ -153,18 +203,25 @@ inspecting the step output for a log line like `"Using token: SPECKIT_PR_TOKEN (
 - **NFR-003**: All error messages produced by the preflight and assignment steps MUST follow GitHub Actions annotation format (`::error::message`) so they surface in the workflow run summary UI, not
   just buried in step logs.
 
-- **NFR-004**: The change MUST be confined to `.github/workflows/speckit-implement-trigger.yml`. No other workflow files, agent definitions, or source code should be modified as part of this fix.
+- **NFR-004**: The change MUST be confined to `.github/workflows/speckit-implement-trigger.yml`. No other workflow files, agent definitions, or source code should be modified as part of this fix. The
+  `permissions` block remains unchanged since PATs carry their own scopes independent of the workflow permissions declaration.
 
-- **NFR-005**: Investigation, remediation, and any subagent-assisted work for this bug MUST include a rubber duck review step to validate reasoning and cross-examine the implementation plan before merge.
+- **NFR-005**: Investigation, remediation, and any subagent-assisted work for this bug MUST include a rubber duck review step to validate reasoning and cross-examine the implementation plan before
+  merge.
 
 ### Key Entities
 
-- **`SPECKIT_PR_TOKEN`**: A Personal Access Token with repository write permissions and Copilot agent assignment scopes. Primary authentication token for privileged speckit pipeline operations.
+- **`SPECKIT_PR_TOKEN`**: A Personal Access Token with repository write permissions and Copilot agent assignment scopes. Primary authentication token for privileged speckit pipeline operations. Passed
+  via the `github-token` input of `actions/github-script@v7`.
 
-- **`COPILOT_GITHUB_TOKEN`**: A fallback PAT with similar scopes to `SPECKIT_PR_TOKEN`. Used when the primary token is not configured. Originally provisioned for Copilot SDK authentication.
+- **`COPILOT_GITHUB_TOKEN`**: A fallback PAT with similar scopes to `SPECKIT_PR_TOKEN`. Used when the primary token is not configured. Originally provisioned for Copilot SDK authentication. Also
+  passed via `github-token` input when used.
 
 - **`agent_assignment` payload**: The API field on the GitHub Issues PATCH endpoint that triggers Copilot coding agent assignment. Requires elevated token permissions beyond what `GITHUB_TOKEN`
-  provides.
+  provides. The response body must contain a non-null `agent_assignment` field to confirm successful processing.
+
+- **`github-token` input**: The authentication input of `actions/github-script@v7` that replaces the default `GITHUB_TOKEN` for the octokit instance. This is the mechanism by which the elevated PAT is
+  injected into the step.
 
 ## Success Criteria
 
@@ -176,7 +233,8 @@ inspecting the step output for a log line like `"Using token: SPECKIT_PR_TOKEN (
 - **SC-002**: When neither `SPECKIT_PR_TOKEN` nor `COPILOT_GITHUB_TOKEN` is configured, the workflow fails within 5 seconds of reaching the preflight step, with a `::error::` annotation visible in the
   GitHub Actions run summary.
 
-- **SC-003**: The workflow run logs for the agent assignment step contain exactly one token-identity log line (either `"SPECKIT_PR_TOKEN (primary)"` or `"COPILOT_GITHUB_TOKEN (fallback)"`) in 100% of
+- **SC-003**: The workflow run logs for the agent assignment step contain exactly one token-identity log line (either `"Agent assignment token: SPECKIT_PR_TOKEN (primary)"` or `"Agent assignment
+  token: COPILOT_GITHUB_TOKEN (fallback)"`) in 100% of
   runs where the step executes.
 
 - **SC-004**: Zero silent failures of agent assignment observed over a 14-day monitoring window post-deployment. A silent failure is defined as: the assignment step reports success but the issue does

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/tests/unit/cli/ci/pipeline/actions/dispatch_repair/test_dispatchrepairaction.py

@@ -496,9 +496,9 @@ class TestDispatchRepairAction:
             action = DispatchRepairAction()
             result = action.execute(provider, snapshot, derived)
 
-        assert result.decision == ActionDecision.EXECUTE
+        assert result.decision == ActionDecision.SKIP
         assert "review_id=4401589029" in result.details
-        assert getattr(derived, "repair_dispatched", False) is True
+        assert getattr(derived, "repair_dispatched", False) is False
         provider.dispatch_repair.assert_not_called()
 
     def test_execute_when_review_id_dedup_check_raises_fail_open(self) -> None:

{agentic_devtools-0.2.164 → agentic_devtools-0.2.165}/tests/unit/cli/ci/pipeline/runner/test_run_pipeline.py

@@ -775,6 +775,75 @@ class TestRunPipeline:
             provider.publish_pr.assert_not_called()
             provider.dispatch_repair.assert_not_called()
 
+    def test_review_request_can_run_after_dispatch_repair_review_dedup_skip(self) -> None:
+        """Review request can still run when dispatch repair dedup path skips."""
+        provider = MagicMock()
+        initial_snapshot = PRStateSnapshot(
+            pr_number=1,
+            head_sha="oldsha",
+            base_branch="main",
+            head_branch="feature",
+            commit_count=2,
+            ci_status="passing",
+            review_state="COMMENTED",
+            copilot_review_id=4401589029,
+            copilot_review_inline_count=2,
+            unresolved_threads=0,
+            is_draft=False,
+            copilot_review_pending=False,
+            base_repo_full_name="org/repo",
+        )
+        refreshed_snapshot = PRStateSnapshot(
+            pr_number=1,
+            head_sha="newsha",
+            base_branch="main",
+            head_branch="feature",
+            commit_count=1,
+            ci_status="passing",
+            review_state="",
+            copilot_review_id=0,
+            copilot_review_inline_count=0,
+            unresolved_threads=0,
+            is_draft=False,
+            copilot_review_pending=False,
+            base_repo_full_name="org/repo",
+        )
+        actions: list[Action] = [
+            DispatchRepairAction(),
+            SquashAction(),
+            RequestReviewAction(),
+        ]
+
+        with (
+            patch(
+                "agentic_devtools.cli.ci.pipeline.actions.dispatch_repair.is_duplicate_trigger",
+                return_value=True,
+            ),
+            patch(
+                "agentic_devtools.cli.ci.pipeline.actions.squash.is_copilot_session_active_via_agent_task",
+                return_value=False,
+            ),
+            patch(
+                "agentic_devtools.cli.ci.pipeline.actions.request_review.is_copilot_session_active_via_agent_task",
+                return_value=False,
+            ),
+            patch(
+                "agentic_devtools.cli.ci.pipeline.runner.build_pr_state_snapshot",
+                return_value=refreshed_snapshot,
+            ),
+        ):
+            summary = run_pipeline(provider, initial_snapshot, actions)
+
+        assert [r.decision for r in summary.results] == [
+            ActionDecision.SKIP,
+            ActionDecision.EXECUTE,
+            ActionDecision.EXECUTE,
+        ]
+        assert summary.results[2].preconditions.get("no_repair_dispatched") is True
+        provider.dispatch_repair.assert_not_called()
+        provider.squash_post_repair.assert_called_once()
+        provider.request_reviewer.assert_called_once()
+
     def _make_pipeline_snapshot(self) -> PRStateSnapshot:
         return PRStateSnapshot(
             pr_number=1,