Verify integration-branch protection for pipelines

.github/plugins/devsquad/agents/devsquad.implement.agent.md

@@ -174,7 +174,7 @@ This agent is an **orchestrator**. The detailed steps are delegated to specializ
 
 **When to use workers vs inline**: Use workers when the step benefits from context isolation (verification, review). Keep steps inline when they require interactive developer dialogue (understanding checkpoint, code question guidance, churn detection).
 
-For **low-impact** tasks, skip steps 3, 5, 8, 9 and apply fast-track (see Impact Classification).
+For **low-impact** tasks, skip steps 3, 5, 8, 9 and apply fast-track (see Impact Classification). Fast-track does not skip pipeline-protection verification when a pipeline is detected.
 
 ## Additional Context
 
@@ -322,6 +322,7 @@ Generic responses ("ok", "go", "do it") should trigger a request for more specif
    - Interrupt execution if any non-parallel task fails
    - **If using tasks.md**: Mark tasks as [X] in the file when completed
    - **If using issue**: Add comment on the issue with progress (if requested)
+   - **Pipeline protection**: When a pipeline is created, changed, or detected, run the read-only Pipeline Protection Check in `engineering-practices` and include the result in completion evidence. This also applies to low-impact pipeline/configuration tasks.
    - Provide clear error messages for debugging
 
    **Cycle per task**:

.github/plugins/devsquad/agents/devsquad.implement.execute.agent.md

@@ -51,6 +51,10 @@ The test must fail BEFORE the fix and pass AFTER. If the test passes before the
 - **Consult harness learnings**: Before coding, read `.memory/harness-learnings.md` (if it exists) and check for entries whose Scope overlaps with the task's files. Apply high-confidence Guidance proactively to avoid known pitfalls.
 - **Context budget**: If the conversation is growing large (many tool calls, long outputs), compress completed work into a brief summary and drop raw intermediate output. Commit progress and request a fresh context window from the coordinator rather than degrading in a bloated context.
 
+### 3a. Pipeline Protection
+
+When creating, changing, or detecting CI/CD pipeline configuration, consult the Pipeline Protection Check in `engineering-practices`. Inspect protection read-only on the repository platform and report verified, missing, or unverified required checks for the integration branch. Do not change repository settings without explicit approval. Return this evidence with the implementation result even when no application code changed.
+
 ### 4. Azure Best Practices
 
 When the project stack includes Azure services, **before generating code** that interacts with Azure SDKs:
@@ -114,6 +118,7 @@ Worker: execute
 Tasks completed: [list of task IDs]
 Files modified: [list]
 Tests written: [list of test files/names]
+Pipeline protection: [not applicable | verified required checks | confirmed gap with recommendation | unable to verify with reason]
 
 Changes made:
 - [file]: [what changed and why]

.github/plugins/devsquad/agents/devsquad.plan.agent.md

@@ -230,6 +230,8 @@ After receiving the worker's analysis, proceed with interactive steps:
 
 #### 2.1 Engineering Practices and DevOps/SRE
 
+**Independent pipeline check**: When CI/CD configuration is created, changed, or detected, run the read-only Pipeline Protection Check in `engineering-practices` using available terminal/CLI/API access. This check also applies when conventions are already defined or the developer skips the optional discussion below. Record repository, integration branch, required check/build policy names, and verified, missing, pending, or access-blocked evidence in the planning result. A successful local build or an existing CI convention is not protection evidence. Do not mutate repository settings.
+
 If this is one of the first features of the project, run the engineering practices assessment using the `engineering-practices` skill.
 
 **Trigger**: Execute when no ADRs or documented conventions exist for CI/CD, branch strategy, observability, or IaC. If the project already has these definitions, ask whether a review is desired and skip if not.

.github/plugins/devsquad/agents/devsquad.plan.architecture.agent.md

@@ -41,7 +41,7 @@ Flag conflicts that must be resolved before proceeding.
 
 ### 3. Engineering Practices Assessment
 
-If this is one of the first features of the project (no ADRs or conventions for CI/CD, branch strategy, observability, IaC), identify that an engineering practices discussion is needed.
+If this is one of the first features of the project (no ADRs or conventions for CI/CD, branch strategy, observability, IaC), identify that an engineering practices discussion is needed. Independently report any detected CI/CD configuration to the coordinator, even when conventions are already defined, so it runs the read-only Pipeline Protection Check. This worker does not have repository-policy query tools, so do not claim protection is verified from configuration alone.
 
 ### 4. Azure Architecture Validation (if applicable)
 
@@ -68,6 +68,7 @@ ADR Conflicts:
 Engineering Practices:
 - Status: [Assessment needed | Already defined]
 - Missing: [list of practices without ADR or convention]
+- Pipeline protection handoff: [detected CI/CD files and integration branch for coordinator verification | no pipeline detected]
 
 Azure Validation: [if applicable]
 - Architecture: [validated/not applicable]

.github/plugins/devsquad/skills/engineering-practices/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: engineering-practices
-description: Socratic guide for engineering practice decisions (DevOps, SRE, CI/CD, branch strategy, observability, IaC). Guides the agent to ask questions based on project context, rather than prescribing solutions. Use during planning of initial features. Do not use for application architecture decisions (use devsquad.plan) or for pipeline/infra creation (use devsquad.implement).
+description: Socratic guide for engineering practice decisions (DevOps, SRE, CI/CD, branch strategy, observability, IaC). Guides the agent to ask questions based on project context, rather than prescribing solutions. Use during planning of initial features and when CI/CD pipelines are created, changed, or detected to verify integration-branch protection. Do not use for application architecture decisions (use devsquad.plan) or for creating pipelines or infrastructure themselves (use devsquad.implement).
 ---
 
 ## Purpose
@@ -27,6 +27,17 @@ Does it already exist or does it need to be created?
 
 Do not suggest baseline as a decision. If everything is covered, confirm and move on.
 
+## Pipeline Protection Check
+
+Run this read-only check when a CI/CD pipeline is created, changed, or detected during a session, including in a small or otherwise fully configured project. Inspect repository protection on the code-hosting platform, which may differ from the work-item platform. This check does not select a new CI platform or branching strategy.
+
+1. Resolve the integration branch from `.memory/git-config.md`, then the repository default branch. Confirm the exact repository and target branch before querying protection. If either is unknown, report verification as blocked rather than guessing.
+2. Identify the CI checks that must pass before merging. Use actual check/job names from pipeline configuration and observed PR runs, including the app identity when available. A workflow filename or successful local build does not establish a required merge check. If names cannot yet be confirmed because the pipeline has not run, report verification as pending.
+3. On GitHub, inspect both classic branch protection and effective active rulesets for the target branch using available read-only tools or authenticated GitHub CLI/API. For example, inspect `GET /repos/{owner}/{repo}/branches/{branch}/protection` and `GET /repos/{owner}/{repo}/rules/branches/{branch}`. Account for branch matching, enforcement, and applicable bypass permissions. Existing protection is insufficient unless the relevant checks are required before merge.
+4. On Azure DevOps, inspect the repository's branch policies for the exact integration branch and confirm the relevant build-validation policy is enabled and blocking. Do not treat an optional, disabled, or differently scoped build policy as protection. Use available read-only tools or an already configured Azure DevOps CLI/API.
+5. Report one of: verified required checks, confirmed missing or incomplete protection, or unable to verify. Include repository, branch, check names, and evidence. Permission errors, authentication failures, unsupported APIs, and ambiguous 404 responses are not proof of missing protection. If access is insufficient, report the error and provide the manual inspection path.
+6. When protection is confirmed missing or incomplete, recommend the specific required-check or blocking build-validation policy and ask for approval before any settings change. Never apply branch protection, alter bypass permissions, or weaken existing rules automatically. In autonomous mode, record the recommendation for the developer instead of applying it without approval.
+
 ## Input
 
 Before exploring decisions, collect the project's operational profile.

CHANGELOG.md

@@ -28,6 +28,7 @@ See `CONTRIBUTING.md` for full conventions.
 ### Changed
 
 - Work item creation now computes the complete required label/tag set, creates missing GitHub labels before issue creation, verifies stored metadata, and reports recoverable partial batches instead of silently continuing. Kickoff and specification agents have the minimum tools needed to apply and repair this metadata.
+- Pipeline creation, changes, or detection now trigger read-only verification of integration-branch protection, including effective GitHub rulesets or blocking Azure DevOps build validation. Missing protection produces a recommendation, while permission errors remain explicitly unverified. Repository settings are not changed without approval.
 - Work item creation and decomposition now explicitly exclude invented sequential task and story identifiers from generated GitHub and Azure DevOps titles. The task quality rubric checks this convention while preserving feature prefixes, domain numbers, native board IDs, hierarchy, and dependency links. Existing work items are not renamed automatically.
 - The `test-discipline` skill now explicitly covers tautological assertions, independent behavioral oracles, and behavior-preserving refactoring. Implementation and review workers and the code quality rubric reinforce these checks. Reuse existing behavioral tests and add tests only for concrete coverage gaps, without requiring mutation-testing tooling or banning legitimate test helpers and computed expectations.
 

docs/src/content/docs/skills/architecture.mdx

@@ -50,7 +50,7 @@ Explores engineering decisions for delivery and operations. The skill uses proje
 **Core responsibilities:**
 | Topic | Detail |
 |------|--------|
-| Delivery workflow | CI/CD structure, release flow, branch strategy |
+| Delivery workflow | CI/CD structure, release flow, branch strategy, and read-only required-check verification when pipelines are created or detected |
 | Operations | Observability, reliability, ownership, incident handling |
 | Infrastructure | IaC approach, environment model, deployment controls |
 | Decision scope | Distinguishes ADRs from team conventions |
@@ -59,7 +59,9 @@ Explores engineering decisions for delivery and operations. The skill uses proje
   This skill is advisory. It guides questions and trade-offs based on project context instead of applying a fixed solution.
 </Aside>
 
-**Activation triggers:** Initial planning, engineering practice selection, platform and process design.
+Pipeline verification checks the integration branch on the repository platform, including effective GitHub rulesets or Azure DevOps blocking build-validation policies. It reports missing protection separately from access errors and recommends changes without applying settings automatically.
+
+**Activation triggers:** Initial planning, engineering practice selection, platform and process design, pipeline creation or changes, and detection of an existing pipeline.
 
 ---