Repository navigation
Allow dependency additions without bypassing protected-file safety #1748
Description
Problem
Squad currently cannot produce a pull request for any task that requires adding or changing a package dependency.
Examples:
- Add Serilog
- Add pytest
- Add lodash
- Add a NuGet central package version
- Add or update a Python, npm, Go, Ruby, Java, Gradle, Deno, Bun, or Elixir dependency
After #1746 / PR #1747, the implement-worker uses:
protected-files:
policy: fallback-to-issue
exclude:
- README.mdThat fixed the signed-commit hard failure, but it also made the consequence explicit: dependency-manifest changes fall back to a protected-file review issue instead of a PR.
That is too limiting. Supply-chain risk is real, but a coding agent that cannot add dependencies is missing a common and legitimate class of work.
Why this is blocked today
gh-aw protects dependency manifests by default. The default protected-files list covers manifests and lockfiles across ecosystems: npm/yarn/pnpm/Bun/Deno, Python, NuGet, Go modules, Ruby gems, Maven/Gradle, and Elixir mix files.
Important mechanics:
- Matching is by basename at any depth, not glob.
package.jsonis protected whether it sits at the repo root or undersrc/Foo/package.json. - The default list is injected unconditionally.
- The list is not replaceable, only narrowable, through
protected-files.exclude. request_reviewis not viable with signed commits — the signed-commit push path re-validates protected-file output and only acceptsallow. That was finding F.excluded-filesis a different mechanism: it strips paths before protected-file evaluation, and is not the right model for this.
So our current practical choices are: keep dependency files protected and fall back to issue, or exclude selected dependency files from protection.
The actual tension
The protected-file guard should prevent routine agent output from quietly normalizing high-leverage changes — dependency graph, install/build/test execution, governance, release provenance, workflow/security posture.
But today we are preventing more than that. We are not just preventing silent dependency changes; we are preventing the agent from producing any PR for legitimate dependency-addition work.
The goal should be: dependency changes are explicit, reviewable, and intentional — not impossible.
Design options
Option 1: Narrow protected-files.exclude per ecosystem
For repos that opt in, exclude selected dependency manifests from protection.
protected-files:
policy: fallback-to-issue
exclude:
- README.md
- package.json
- package-lock.json
- pyproject.toml
- requirements.txt
- Directory.Packages.propsPros: Simple. Works with gh-aw as-is. Lets common dependency tasks produce PRs. Tailorable per repo/ecosystem.
Cons: Basename-anywhere matching means excluding package.json affects every nested package.json. Coarse-grained — cannot distinguish "add lodash" from a riskier script or package-manager change. Review safety depends on Squad presentation, labels, and reviewer discipline.
Option 2: Make dependency-change support an adoption-time repo choice
During Squad adoption/preflight, ask whether the repo allows dependency-addition PRs. Modes: strict (always fall back to issue), ecosystem opt-in, or permissive (allow manifests/lockfiles but mark PRs clearly).
This should live near the same adoption-time surface as finding E — the preflight for Settings → Actions → Allow GitHub Actions to create and approve pull requests.
Pros: Makes this a conscious repo-owner decision. Avoids one global policy pretending to fit every repo. Gives us a natural place to explain the risk.
Cons: More setup complexity. Requires encoding and persisting repo policy. Existing repos need migration/default behavior.
Option 3: Dedicated dependency-change flow
Keep dependency files protected by default, but add a first-class dependency-change workflow that requires the issue to explicitly request a dependency addition, generates a PR with a clear dependency-change label, includes package name/version/ecosystem rationale, surfaces install/test evidence, and requires human approval before merge.
Under the hood this still likely uses protected-files.exclude, but only for repos/workflows that choose this path.
Pros: Best matches the real risk model. Makes dependency changes conspicuous instead of routine. Gives reviewers the right context.
Cons: More workflow design work. Still constrained by basename-level exclude behavior. Needs careful UX so it does not feel like a failed worker.
Option 4: Treat manifests and lockfiles differently
Variants: allow manifest edits and require lockfile regeneration and review; allow lockfile updates only when paired with manifest changes; protect package-manager config more strongly than ordinary manifests; allow app-level manifests but keep governance files like NuGet.Config protected.
Pros: More precise than blanket allow/block. Reflects ecosystem-specific risk. Prevents dangerous config/provenance changes while allowing ordinary package adds.
Cons: Hard to express with a basename matcher. Ecosystems differ significantly. Could become confusing without strong defaults.
Recommendation
Adopt Option 2 plus Option 3.
Make dependency-addition support an adoption-time repo choice, then route enabled repos through a dedicated dependency-change path that produces PRs with explicit review context.
Default posture stays conservative for existing repos: dependency changes fall back to issue unless the repo opts in. For opted-in repos, Squad narrows protected-files.exclude only for the selected ecosystem files and makes resulting PRs visibly dependency-related through title, body, labels, and checklist.
This keeps the safety principle from #1746 / PR #1747, but stops treating package addition as prohibited work.
Open questions
- Should dependency-addition PRs be opt-in per repo, or allowed by default for Squad-managed repos?
- Which ecosystems should we support first — npm, NuGet, Python, or all common manifest types?
- Should lockfiles be allowed in the same mode as manifests, or handled separately?
- Are package-manager config files like
NuGet.Config,.npmrc, or registry config always protected even when dependency manifests are allowed? - Should dependency-change PRs require a special label or reviewer checklist before merge?
- Should the adoption preflight combine this with finding E so repo owners make one explicit "agent can create PRs / agent can change dependencies" decision?
Related
- Worker
protected-files: request_reviewis incompatible with signed commits (finding F) #1746 / PR fix(worker): use fallback-to-issue for protected files #1747 — the protected-files policy change this falls out of - Finding E — the Actions PR-creation preflight this should likely share a surface with
Activity
bradygaster commentedon Aug 19, 2026
Decision on open question 1 — allowed by default, opt-out rather than opt-in.
Package additions should be permitted by default. Repos that want to prohibit dependency changes opt out explicitly.
Rationale: blocking agents from adding npm / NuGet / pip packages is a hostile default. The common case is legitimate — an agent implementing a feature frequently needs a package, and a hard prohibition turns ordinary work into a dead end instead of a reviewable change. Safety comes from the change being explicit and reviewable, not from it being impossible.
This inverts the Option 2 recommendation above: the adoption-time configuration surface exposes a disable toggle, not an enable toggle.
Consequences to fold into the design:
bradygaster commentedon Aug 20, 2026
Flight sequencing note — revised 2026-08-20.
Wave: 2.
Depends on:
Blocks: nothing else in this stream directly.
Safe to run in parallel with: #1756 and #1759 after #1762 is decided; #1770, #1760, #1772, and #1768 at any time. Be cautious with #1761 only if both edits rewrite the same gh-aw guide setup prose.
Why / evidence: #1748's policy lives in the implement worker protected-file safe-output area:
workflows/squad-implement-worker.mdlines 170-181 document the currentfallback-to-issueposture and only excludeREADME.md; lines 178-196 define the structural protected/excluded-file guard. #1762's related setup/preflight material is elsewhere:docs/src/content/docs/guide/gh-aw.mdlines 63-82 already document the Actions setting, andworkflows/squad.mdlines 420-451 are the connect/adopt paths where a shared preflight would belong. Noworkflows/squad.mdhunk overlaps #1756/#1759's prompt blocks.babyblueviper1 commentedon Aug 20, 2026
On the basename-matching mechanics: worth separating two questions that the current protected-files check conflates into one policy decision.
"Is this file a dependency manifest" and "is this specific change to it risky" are different axes. A new package name being introduced for the first time (unknown provenance, unaudited transitive tree, name-squatting/typosquat surface) is a materially different risk than a version bump on a package the repo already depends on and has presumably already vetted once. Basename-at-any-depth matching only answers the first question — it can't distinguish
"lodash": "^4.17.21"->"^4.17.23"from adding a brand-new, never-seen-before package name to the same file, even though the second is the actual supply-chain attack surface (event-stream,ua-parser-js,node-ipcwere all typosquat/compromise incidents on additions or takeovers, not routine bumps).That argues for a third axis inside Option 4 rather than a fifth option: for manifest-diff review, classify each changed line as
new-dependency/version-bump/removed, not just "manifest touched." A repo could then reasonably setversion-bump: allow,new-dependency: fallback-to-issueas defaults — which gets close to Option 2's opt-in spirit without needing a separate adoption-time toggle, since the risk-appropriate default falls naturally out of the diff classification rather than a binary per-repo setting.The open question this doesn't answer: whether a lockfile-only change (no manifest touch, e.g. a transitive dep updating under a caret range) should classify the same way — that's a real gap in a diff-based classifier that a basename check sidesteps by being coarse in the first place.
chore(squad): repair archival data loss and record gh-aw triage sessi…
bradygaster commentedon Aug 25, 2026
Flight Decision — #1748: Dependency-Addition Support
Status: APPROVED — IMPLEMENTATION-READY (2026-08-25; proceed under the finalized slices and acceptance criteria below)
Prepared by: Flight (Lead)
Date: 2026-08-25
Executive Recommendation
Introduce a dedicated
squad-deps-workercompiled with dependency manifest exclusions, and keep the existingsquad-implement-workerunchanged (all manifests remainfallback-to-issueon the general path). Per-repo opt-out is prompt-enforced via.squad/config.jsonkey"squadDeps"— not structural — because gh-awprotected-files.excludeis resolved at compile time (safe_outputs_config_generation.go:sliceutil.Exclude()) and cannot read a runtime repo file.Brady's decision on default-on is fixed. This decision synthesizes all specialist inputs. All four design choices have been resolved by Brady (see §Resolved Decisions below); implementation may proceed.
Rejected alternatives
protected-files: allowedsrc/*/package.jsononly)manifest_file_helpers.cjs:301-305:file.split("/").pop())request_reviewpolicycheckFileProtectionPostApplythrowsSigned-commit payload violates file-protection policyfor anything other thanallow; confirmed #1746excluded-filesexpansion.squad/config.jsonstructural gateprotected-files.excludeis compile-time, baked into.lock.yml; there is no hook for the runtime worker to read.squad/config.jsonand conditionally change the compiled exclusion setprotected-files. No structural mechanism prevents a generalworkflow_dispatchfrom touching manifests once exclusions are compiled in. See §Dedicated Workflow / Path Authority.File-Class Policy Matrix
package.json,pyproject.toml,go.mod,pom.xml, etc.)fallback-to-issue)package-lock.json,go.sum,Gemfile.lock,yarn.lock, etc.)fallback-to-issue)NuGet.Config,bunfig.toml,.npmrc,.yarnrc.yml)global.json)CODEOWNERS,SECURITY.md,CONTRIBUTING.md,CHANGELOG.md,CODE_OF_CONDUCT.md,DESIGN.md)AGENTS.md)copilot_engine.go:147-151; stays protected regardless of exclude listsetup.py,setup.cfg)runtime_definitions.go;setup.pyexecutes code on install — PR body must call this out explicitlygradle.properties)ext {}blocks); reviewer responsibility for build-property changesnode_modules/,vendor/, generated caches, build artifacts)excluded-filesexpansion is the correct mechanism). Any exception requires a separate, explicitly scoped human-owned authority outside Squad's dependency path.bunfig.tomlruling (DECIDED): Keep protected.runtime_definitions.golists it underManifestFilesalongsidepackage.jsonandbun.lockb, but it controls Bun registry endpoints and install behavior — identical risk profile to.npmrc. Flight recommendation: do not exclude. Brady approved: keep protected.Concrete Config Schema
protected-files.exclude— lives inworkflows/squad-deps-worker.md(new file; see §Dedicated Workflow)This is the only structural mechanism available. The compiled
.lock.ymlbakes exclusions in atgh aw add/gh aw compiletime. No runtime repo file can change the compiled exclusion set. The general worker (squad-implement-worker.md) retains its current config unchanged; only the dependency worker carries manifest exclusions.Always-protected regardless of opt-out or ecosystem scope:
NuGet.Config,global.json,bunfig.toml,CODEOWNERS,SECURITY.md,CONTRIBUTING.md,CHANGELOG.md,CODE_OF_CONDUCT.md,DESIGN.md,AGENTS.md,.npmrc,.yarnrc.yml.allowed-filesgap (Slice S1, required before S2): The currentallowed-filessection (squad-implement-worker.md:62-169) uses extension-only patterns. Extensionless manifests —go.mod,go.sum,Gemfile,Gemfile.lock,Pipfile,Pipfile.lock,yarn.lock,bun.lockb,mix.exs,mix.lock,pom.xml— match no existing pattern (confirmed by FIDO,test/gh-aw-implement-workflow.test.ts:62-169analysis). These basenames must be added as explicitallowed-filesentries in the new dependency worker. S1 and S2 must land in the same PR, atomically, to prevent a state where files are unprotected but also un-allowed.Note:
allowed-filesandprotected-filesare independent checks (manifest_file_helpers.cjs:checkFileProtection). A file matching*.jsoninallowed-filesstill hits the basename protected-files check —allowed-filesdoes not suppress it. Theexcludelist is the exclusive unblock mechanism.Per-repo opt-out (prompt-level only)
Config key:
"squadDeps"in.squad/config.json. Follows existing camelCase convention (workflows/squad.mdsquad-connect step 3, squad-adopt step 3). One new key; no new config schema.Exact schema and fail-closed semantics:
squadDepsvalue"allow""deny"nullPrompt instruction to add to
squad-deps-worker.md(Implement section, step 1a):Runtime config does NOT dynamically change compiled exclusions. The compiled
.lock.ymlalways reflects the exclusion list baked in at compile time. The prompt guard above controls agent behavior only — it does not alter which files gh-aw's structural protection gates apply to.Explicit limitation to state in docs and release notes: This guard is prompt-level, not structural. A malfunctioning or adversarially prompted agent could bypass it. The structural fallback is the PR review process: dependency-change PRs are visible, labeled, and subject to whatever branch protection and CODEOWNERS rules exist in the consuming repo.
Dedicated Workflow / Path Authority
Decision: a genuinely distinct
squad-deps-workeris the correct design. DECIDED — Brady approved.A prompt paragraph inside the general implementation worker does not prevent that worker from silently becoming the dependency path once manifests are globally excluded from its
protected-files. Once exclusions are compiled in, any task dispatched to the worker — including a generalworkflow_dispatch— can touch manifests. There is no structural mechanism beyond the prompt guard that prevents this.Structural design (recommended):
squad-implement-worker.mdretains its currentprotected-files.policy: fallback-to-issuefor ALL manifests with no exclusions added. General implementation tasks continue to fall back to issue for any manifest write — unchanged from today.squad-deps-worker.md(new file) is compiled with Wave 1 manifest exclusions. It is dispatched only by explicit dependency intent. It carries the dependency-change guard (step 1a) and full PR presentation requirements.workflow_dispatchfor a general task hitssquad-implement-worker(no manifest access). Only dependency-intent dispatch reachessquad-deps-worker.Why this is stronger than a single-worker with prompt-only guard:
fallback-to-issueprotection for manifests is structural (compiled into.lock.yml) and cannot be bypassed by prompt injection, misfired dispatch, or agent miscommunication.squad-deps-worker, not from a general implementation run.workflow_dispatchauthorization: directworkflow_dispatchtosquad-deps-workerrequires explicit human action withcontents: writepermission. Squad cannot prevent this (operator action outside the control plane), but it is auditable. The general worker has no such surface.Fail-closed behavior (deps worker):
squadDeps: deny(or unrecognized value, unreadable config) → agent stops and comments on issue; no PR created; no manifest touchedsquadDeps: allow(or absent) → agent proceeds; excluded manifests receive signed commits normally (excluded files returnaction: allowfromcheckFileProtectionPostApply)NuGet.Config,AGENTS.md) →fallback-to-issuestill fires regardlessRejected alternative now reversed: "Separate dependency workflow — same protection model; adds registration complexity for no structural gain." This was incorrect. A separate worker compiled without manifest exclusions provides genuine structural isolation. The complexity cost is one new workflow file and one additional
gh aw addstep at adoption. The structural gain is that the general path retains its currentfallback-to-issueprotection for manifests unconditionally. Flight reverses this rejection. (DECIDED — Brady approved dedicated worker; see §Resolved Decisions.)PR Presentation Rules
Required for every PR produced by
squad-deps-workertouching a dependency manifest or lockfile:deps:(example:deps: add lodash 4.17.21 for string utilities (#42))dependency-changedependency-change; exact description:Dependency manifest or lockfile change produced by squad-deps-worker; exact color:#e6f3ff(blue-tinted, visually distinct fromsquadpurple)squad-deps-workercreates the label if absent in the consuming repo. If provisioning fails (insufficient permissions), this is treated as a hard failure — the worker stops and posts a comment on the issue stating that the requireddependency-changelabel could not be established. A PR is NOT created without the label. Repo operators must grant the agent label-provisioning permission or pre-create the label. Adoption guide must document this requirement.## Dependency Changescontaining:npm ci --frozen-lockfile)npm audit --audit-level=moderate,pip audit,govulncheck ./..., etc.)npm ci --frozen-lockfile). Verify locally by running[install command] --frozen-lockfile."node_modules/,vendor/, or generated cache directories. If any appear in the diff, do not merge."Human approval (Category C — external): Squad cannot enforce required human approval before merge. That requires branch protection and/or CODEOWNERS review rules in the consuming repo. The PR body must note: "We recommend enabling required-reviewer rules or the GitHub Dependency Review action for manifest files in your branch protection settings." Squad's PRs are subject to whatever protection rules exist; Squad cannot bypass them.
Ecosystem Scope and Expansion Criteria
Decision: phased rollout across three waves. Evidence basis:
workflows/squad-implement-worker.md:34-43(network.allowed).The worker's
network.allowedlist (squad-implement-worker.md:34-43) includes:defaults, containers, dotnet, go, java, node, python, ruby, rust. It does not includedeno,bun, orelixir. Without anetwork.allowedtoken, the agent cannot rundeno install,bun install, ormix deps.getto regenerate lockfiles in the CI environment. Shipping manifest exclusions for those ecosystems beforenetwork.allowedis extended means the agent can edit manifests but cannot produce a verifiable frozen lockfile. This is a material gap.Wave 1 (initial PR —
squad-deps-worker.mdcreation): npm/yarn/pnpm + NuGet central package management + Gonetwork.allowedcoverage:node(line 41),dotnet(line 38),go(line 39)NuGet.Configandglobal.jsonremain protected in all wavesWave 2 (separate PR, after Wave 1 merged and validated): Python/uv + Ruby
network.allowedcoverage:python(line 42),ruby(line 43)setup.pycode-execution risk (executes on install); confirmuv.lockregeneration command; confirmbundle install --frozenevidence formatWave 3 (separate PR, after Wave 2 merged): Maven/Gradle + Deno/Bun + Elixir
java(line 40) innetwork.allowed, butsettings.gradleregistry-config boundary and Gradle plugin portal trust must be defined before includingnetwork.allowed— requiresnetwork.allowed: [deno]extension insquad-deps-worker.mdAND explicit Brady approvalnetwork.allowed— same requirement; additionallybunfig.tomlis confirmed protected (DECIDED — see §Resolved Decisions feat: worktree awareness, Scribe auto-commit, and decision consolidation #1)network.allowed— requiresnetwork.allowed: [elixir]extension AND explicit Brady approvalnetwork.allowedentry, defined frozen-install command, structural test, integration testHaskell and Rust: Not included in any wave above without explicit verification and Brady scoping decision.
cargo):rustIS innetwork.allowed(line 44).Cargo.toml/Cargo.lockare well-defined. Can be added to Wave 3 with explicit Brady approval and a structural test.stack): NOT innetwork.allowed. Requiresnetwork.allowedextension + explicit Brady decision + integration test.Objective expansion criteria (any ecosystem, any wave):
network.allowedtoken is present insquad-deps-worker.mdprotected-files.excludeANDallowed-filesatomically (S1+S2 pattern)Migration / Backward Compatibility
Breaking behavior change for all repos already running Squad post-#1747:
squad-implement-worker)squad-deps-worker) → PR withdependency-changelabelDirectory.Packages.propschange → issueDirectory.Packages.propschange via deps worker → PRfallback-to-issueon general pathfallback-to-issue(unchanged). Deps worker: Wave 1 manifests excludedRequired actions:
squad-deps-workerdispatch path. General implementation tasks continue to fall back to issue for manifest writes. Dependency-intent tasks must be explicitly dispatched to the new worker."squadDeps": "deny"to.squad/config.jsonto prevent the deps worker from touching manifests.gh aw add bradygaster/squad/workflows/squad-deps-worker.md@dev. The general worker (squad-implement-worker.md) is unchanged and does not need recompilation for this feature. The installed.lock.ymlembeds the compile-time exclude list — editing the source.mdin this repo alone has no effect on already-installed workflows (confirmed: PR fix(worker): use fallback-to-issue for protected files #1747 body, "Workflow source changes must be recompiled").Threat Model
NuGet.Config,bunfig.toml,.npmrcalways protected — deps worker structurally cannot touch them (B+A)squad-implement-workerretainsfallback-to-issuefor ALL manifests (no exclusions); onlysquad-deps-workerhas exclusions (B)workflow_dispatchtosquad-deps-workerby a human withcontents: writeis an operator action outside Squad's control planenode_modules/,vendor/, caches)excluded-filesexpansion insquad-deps-worker.mdmust strip these paths structurally; PR body requires explicit no-vendored-content confirmation (B+A)excluded-filesexpansion is not implemented; structural expansion is correct mechanismsetup.py, npmpostinstall, Gradle tasks)setup.py/setup.cfgchanges; reviewer directed to inspect hooks (A)npm ci --frozen-lockfileor equivalent.env-like files not inallowed-files.squad/config.json, not issue body (A)squadDepsvalue"allow"/"deny"→ deny immediately (A)Implementation Slices
S1, S2 must land atomically in one PR (new
squad-deps-worker.md, Wave 1 scope). {S3, S4} in parallel after S1+S2. S5 after S3. S6 accompanies each slice (TDD preferred). Waves 2 and 3 are separate PRs with separate Brady approvals.squad-deps-worker.mdwith Wave 1allowed-filesfor extensionless manifest/lockfile basenamesworkflows/squad-deps-worker.md(new)go.mod,go.sum,yarn.lock,package-lock.jsonappear inallowed-files; new test assertssquad-implement-worker.mdhas NO manifest exclusionsprotected-files.excludein deps workerworkflows/squad-deps-worker.mdNuGet.Config,.npmrc,bunfig.tomlNOT in exclude; T4: policy isfallback-to-issue; T6: compiled.lock.ymlconfig reflects exclusions; T7:package-lock.jsonin bothallowed-filesandexcludeworkflows/squad.mdconnect/adoptworkflows/squad.md(~lines 420-451)workflows/squad-deps-worker.md(prompt body)docs/src/content/docs/guide/gh-aw.mdsquad-deps-workerdispatch, opt-out key with exact schema, what stays protected; #1762 closed/docs-only acknowledged; dependency authorization surfaced alongside PR-creation capability for discoverability but documented as a separate policy decisiontest/gh-aw-deps-workflow.test.ts(new),test/gh-aw-implement-workflow.test.ts(add: general worker MUST NOT have manifest exclusions)Assignment recommendation: S1+S2+S6 → Procedures (with FIDO writing/reviewing tests). S3 → Procedures. S4 → Procedures. S5 → PAO. All Wave 1 slices: wave:2.
Dependency Authorization and Adoption Preflight (#1762)
Decision: do not merge these concerns.
#1762 is closed (docs-only): Brady decided documentation at
docs/src/content/docs/guide/gh-aw.md:63-82suffices for the Actions PR-creation setting; runtime preflight probe deferred tosquad health(#1605). The dependency opt-out ("squadDeps": "deny") is a developer configuration choice, not a setup prerequisite.Adoption/setup answer: The dependency authorization setting (
squadDeps) may be surfaced in the same setup/adoption report as the PR-creation capability (Actions write permission) for discoverability — both are relevant at onboarding time. However, they are separate policy decisions and must not be conflated: the Actions setting controls whether the agent can create PRs at all;squadDepscontrols whether dependency manifests may be touched. These have different owners and different opt-out surfaces. #1762 being closed/docs-only does not imply thesquadDepsdecision is also docs-only — it requires implementation in S3 and S4.Resolved Decisions (Brady Approved — 2026-08-25)
All four design choices are decided. Default-on is fixed (Brady decided previously). Implementation may proceed.
bunfig.toml: exclude (treat as manifest) or keep protected (treat as registry config)?.npmrc. Theruntime_definitions.gogrouping withManifestFilesreflects gh-aw's generic model, not Squad's product model. Brady approved.fallback-to-issue?fallback-to-issueis hostile for normal maintenance. Both the callout and frozen-install evidence are required, not optional. Brady approved.dependency-changelabel provisioning: worker creates if absent, or must be pre-provisioned?squad-deps-workercreates the label if absent. Exact label: namedependency-change, descriptionDependency manifest or lockfile change produced by squad-deps-worker, color#e6f3ff. If the worker cannot establish the required label (insufficient permissions), it fails closed — stops and posts a comment; no PR is created without the label. Brady approved.squad-deps-workervs. single-worker with prompt-only guard?squad-deps-worker. General worker retainsfallback-to-issuefor all manifests unconditionally; only deps worker has exclusions. Prompt-only separation in a single worker provides no structural isolation and cannot claim 'no bypass.' Brady approved.S1: scaffold squad-deps-worker (fail-closed dependency-manifest worke…
test(#1748): fix policy mutation tautology and add T1 cardinality guard
fix(s2): cover all nested bin output; replace tautological mutation test
test(s2): strengthen T8b with path.matchesGlob to prove nested bin ex…
bradygaster commentedon Aug 25, 2026
Reopened after merge of PR #1883. That PR delivered S2 only (Wave-1 protected-files exclusions) and intentionally used Part of #1748; S3 dispatcher/config routing, S4 evidence/label behavior, and S5 docs/setup reporting remain outstanding. This issue must stay open until all acceptance criteria are satisfied.
fix: install dependency worker with dispatcher
S3: route dependency tasks to squad-deps-worker (#1748) (#1888)
S2: add Wave 1 protected-files.exclude to squad-deps-worker (github#1748