hve-squad

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

There is a pre-release process that creates a pre-release tag of what is being merged to main but the official release stays intact. Like the current situation, we are at v0.16.1 but the pre-release is at v0.16.2-pre
Users can always use the pre-release if they wish to but it is always better to use the latest one as it is tested.

https://github.com/Peter-N91/hve-squad/tags
https://github.com/Peter-N91/hve-squad/releases

Repository on GitHub, which uses git. git is distributed.

Releases and tags are unique for each release and changelog explains what changes.

https://github.com/Peter-N91/hve-squad/tags
https://github.com/Peter-N91/hve-squad/releases
https://github.com/Peter-N91/hve-squad/blob/main/CHANGELOG.md

Tags are used https://github.com/Peter-N91/hve-squad/tags

Non-trivial release notes file in repository: https://github.com/Peter-N91/hve-squad/blob/main/CHANGELOG.md.

release notes file in repository: https://github.com/Peter-N91/hve-squad/blob/main/CHANGELOG.md.

Bug reports are submitted through the GitHub issue tracker at https://github.com/Peter-N91/hve-squad/issues, which is open to the public and requires only a GitHub account. A structured Bug report form at .github/ISSUE_TEMPLATE/bug-report.yml collects the installed version, the Copilot host, expected against actual behaviour, reproduction steps, and optional squad state. The "Reporting a bug" section of CONTRIBUTING.md documents the process and the two exceptions: security vulnerabilities go privately through GitHub Security Advisories as described in SECURITY.md, and defects in upstream microsoft/hve-core assets are directed to that repository. .github/ISSUE_TEMPLATE/config.yml surfaces both routes directly in the issue-creation chooser.

Some of the issues can be labeled to squad/auto and have the squad itself handle them. The history of the squad member will be saved under .copilot-tracking

Reports and responses are archived publicly in the GitHub issue tracker at https://github.com/Peter-N91/hve-squad/issues?q=is%3Aissue, which lists open and closed issues together. The archive is readable without a GitHub account, is indexed by GitHub's full-text search across titles, bodies, and comments, and every issue and comment has a stable, permanently addressable URL. It currently holds 16 issues, 15 of them closed with the discussion and resolution intact, alongside 82 pull requests at https://github.com/Peter-N91/hve-squad/pulls?q=is%3Apr, where most defect fixes are discussed and linked back to the issue they close. Nothing is deleted on closure, so the reasoning behind a past fix stays retrievable.

All vulnerabilities will be shown under this tab and handled by contributors

https://github.com/Peter-N91/hve-squad/security/code-scanning

Private vulnerability reports are supported through GitHub Security Advisories at https://github.com/Peter-N91/hve-squad/security/advisories/new. Private vulnerability reporting is enabled on the repository, so any GitHub user can open a report that is visible only to the reporter and the maintainer until an advisory is published. Submission is over HTTPS. The process is documented in SECURITY.md, which states explicitly that vulnerabilities must not be filed as public issues, lists what to include (affected version or commit, component, reproduction steps, observed impact, suggested mitigation), and commits to acknowledgement within 5 business days and a status update within 10. The same private route is surfaced in the issue-creation chooser through .github/ISSUE_TEMPLATE/config.yml and in the Bug report template, so a reporter who starts down the public path is redirected before disclosing anything.

All vulnerabilities were treated in a single day.

The build is automated in PowerShell and driven from CI. scripts/Build-SquadPlugin.ps1 deterministically assembles the distributable Copilot CLI plugin from the squad-src/ tree and is invoked by .github/workflows/publish-plugin.yml on every release tag; it can also be run locally as a manual fallback. scripts/Update-ApmDependencies.ps1 regenerates the apm.yml dependency manifest and apm.lock.yaml from source, and .github/workflows/pr-validation.yml re-runs it on every pull request to verify the checked-in manifest matches what the build produces. Modifying source under squad-src/ and re-running either script yields updated artifacts with no manual steps. External dependencies (microsoft/hve-core) are fetched at install time by APM and are not rebuilt here.

The build uses PowerShell 7 (pwsh), a widely adopted cross-platform build and automation tool, rather than a project-specific build system. Named build targets are declared in the scripts: section of apm.yml (sync-deps, install-sync, change, release-prep), which serves the same role as make targets and gives contributors a single documented entry point per task. The APM CLI performs dependency resolution and installation, and GitHub Actions orchestrates the build in CI. All of these are standard, off-the-shelf tools; the project defines no custom build engine or DSL.

Every tool in the build chain is FLOSS. The build scripts run on PowerShell 7 (MIT), dependency resolution and installation use the APM CLI (microsoft/apm, MIT), source and ref handling uses Git (GPL-2.0), the plugin packaging path uses Node.js and npm (MIT / Artistic-2.0), and release automation uses the GitHub CLI (MIT). No proprietary compiler, SDK, or build tool is required. The build is not Windows-dependent: PowerShell 7 is cross-platform and CI executes the same scripts on Ubuntu runners, so a contributor can reproduce the full build on a Linux machine using only free/libre software.

The project uses Pester 5.7.1 (Apache-2.0), a FLOSS test framework for PowerShell, across three automated suites in tests/: Tier 0 conformance (tests/tier0/) validates the package manifest and shipped asset structure, Tier 1 behavior (tests/tier1/) validates the squad state contract and coordinator assertions against recorded scenarios, and Tier 2 semantic (tests/tier2/) compares live squad runs against stored baselines. Each tier has a runner script (Invoke-Tier0Tests.ps1, Invoke-Tier1Tests.ps1, Invoke-Tier2Tests.ps1) that can be executed locally with pwsh. All three run in CI on every pull request via .github/workflows/tier0-conformance.yml, tier1-behavior.yml, and tier2-semantic.yml, which document the exact install and invocation steps. The test suites and their fixtures are MIT-licensed as part of this repository.

Tests are invoked in the standard way for PowerShell. Each suite is executed through Invoke-Pester with New-PesterConfiguration, the conventional Pester entry point, wrapped in a per-tier runner script (tests/tier0/Invoke-Tier0Tests.ps1 and equivalents for Tier 1 and Tier 2). The wrappers are required because the suites are parameterised through New-PesterContainer -Data, so they cannot be discovered by a bare Invoke-Pester call. A single-command entry point is also declared as the test target in the scripts: section of apm.yml, so apm run test runs the fast conformance suite in the same way make check would. CI invokes the same runner scripts, so local and CI invocation are identical.

The project practises continuous integration against a single central repository. All changes land on main through squash-merged pull requests, with 103 commits integrated in the last 30 days, and branches are short-lived. Every pull request triggers automated validation in GitHub Actions: .github/workflows/tier0-conformance.yml installs the package the branch would deliver and runs the Pester static conformance suite against it, and .github/workflows/pr-validation.yml verifies release state and change-fragment hygiene. Security analysis runs on the same trigger through CodeQL, Zizmor, Checkov, and OpenSSF Scorecard. The same Tier 0 workflow is reused as the release gate via workflow_call, so the check that guards a merge is the check that guards a tag. Merged work is rebuilt onto a rolling pre-release tag within minutes, keeping the integrated state continuously installable and testable.

The policy is documented in the "Automated tests" section of CONTRIBUTING.md: major new functionality must come with tests. A pull request adding a new agent, routing rule, gate, or any consumer-observable behavior is expected to add or extend a case in the automated suite. Documentation, wording fixes, and behavior-preserving refactors are exempt, and a maintainer may waive the requirement for behavior that cannot be asserted without a live model run, stating so on the pull request. The policy is enforced at review time through a Tests checklist in the pull request template, which asks the contributor to confirm the case was added, declared in tests/squad-behavior-contract.md with a citation to the source file stating the rule, and that apm run test passed locally.

The automated suite was introduced on 2026-08-20 and the policy has been followed since. Of the sixteen changes merged after that date, ten added or extended test cases. Every change to squad behavior shipped a regression case traced to a numbered entry in tests/squad-behavior-contract.md: PR #79 (state records survive on every host, 5 test files), #81 (Scribe line-number leakage, 3), #82 (Deliverable Root binding, 5), #83 (deliverable path truncation, 4), #84 and #85 (ledger arithmetic and turn accumulation, 3 and 4), #87 (Init floor record, 2), and #89 (dispatch-backed ledger rows, 3). The most recent feature work, PR #86, added four test files alongside the behavior change. Changes merged without tests are confined to build and release workflow fixes (#92, #93, #94), which sit outside the suite's scope of asserting the shipped asset package.

The policy is documented in the instructions for change proposals in two places. CONTRIBUTING.md carries an "Automated tests" section stating that major new functionality must come with tests, naming the exemptions (documentation, wording fixes, behavior-preserving refactors) and the maintainer waiver for behavior that cannot be asserted without a live model run. It also explains the three test tiers, how to run each locally, and the required Pester version. The pull request template at .github/pull_request_template.md is injected into every pull request description and includes a Tests checklist asking the contributor to confirm that a case was added or extended, that it was declared in tests/squad-behavior-contract.md with a citation to the source file stating the rule, and that apm run test passed locally. Contributors therefore see the policy both before and during change proposal.

The project uses PSScriptAnalyzer, the standard FLOSS linter for PowerShell, over scripts/ and tests/, which together contain all executable code the repository authors. It runs on every pull request and push to main via .github/workflows/lint-powershell.yml, blocks the build on Error-severity findings, and publishes all findings as SARIF to the GitHub Security tab. Rule configuration lives in PSScriptAnalyzerSettings.psd1 at the repository root, so contributors get identical results in VS Code and in CI; the two excluded rules each carry a written justification in that file. In addition, the build scripts and test runners set Set-StrictMode -Version Latest and $ErrorActionPreference = 'Stop', PowerShell's equivalent of a safe language mode. Three further FLOSS analysers run on the same trigger: CodeQL for Python, Zizmor for GitHub Actions workflows, and Checkov for infrastructure-as-code.

All PSScriptAnalyzer findings are addressed. Actionable findings were fixed rather than suppressed: five empty catch blocks now record why the failure is deliberately ignored, seven inconsistent pipeline continuations were realigned, and a line-numbering loop that relied on a cross-scriptblock counter was rewritten. Findings that are genuine false positives are marked in the source with [Diagnostics.CodeAnalysis.SuppressMessageAttribute] carrying a written justification; these cover parameters PSScriptAnalyzer cannot resolve across Pester's separate discovery and run scopes, and a parameter-set selector consumed through $PSCmdlet.ParameterSetName. Two rules are excluded repository-wide in PSScriptAnalyzerSettings.psd1, each with a documented reason: PSAvoidUsingWriteHost, because these are interactive CLI scripts whose console output is the intended behaviour, and PSUseBOMForUnicodeEncodedFile, because every script begins with a #!/usr/bin/env pwsh shebang that a byte-order mark would break on the Linux runners CI uses. The remaining 22 findings are all Warning or Information severity across 5,506 lines of PowerShell, a rate of 0.40 per 100 lines, and none is Error severity. The CI gate blocks the build on Error severity.

The project enables strict checking wherever it is practical. PSScriptAnalyzer runs with IncludeDefaultRules = $true and reports at all three severities (Error, Warning, Information) rather than errors alone, so nothing is filtered out before a human sees it. Only two rules are excluded repository-wide, each with a written justification in PSScriptAnalyzerSettings.psd1, and individual false positives are marked at the call site rather than by broadening those exclusions. Every script and module additionally runs under Set-StrictMode -Version Latest, PowerShell's strictest language mode, which turns references to uninitialized variables, non-existent properties, and malformed method calls into terminating errors, combined with $ErrorActionPreference = 'Stop' so no error is silently swallowed. Three further analysers run at their default full rule sets on every pull request: CodeQL for Python, Zizmor for GitHub Actions workflows, and Checkov for infrastructure-as-code, with Checkov configured as blocking and accepted findings requiring a justified inline checkov:skip.

The project has a single primary developer, who initiated it, authors its releases, and receives private vulnerability reports. Familiarity with secure design is evidenced in the architecture rather than asserted. The system is built around a small number of deliberately narrow human gates rather than a broad permission model (economy of mechanism), and those gates deny by default: an autopilot run stops at any impactful or irreversible action and proceeds only on explicit human approval, never on a timeout (fail-safe defaults). Progress is non-bypassable, since each pipeline stage is gated on the prior stage's artifact and history entry existing on disk, so a stage cannot be skipped by narrating it as complete (complete mediation). The entire design, including every gate and routing rule, is public under an MIT licence and depends on enforcement rather than obscurity (open design). Impactful actions require two independent conditions, the agent's proposal and a human approval delivered through a separate channel (separation of privilege). CI workflows declare an empty top-level permissions: {}, grant the minimum scope per job, and check out with persist-credentials: false (least privilege), while test runs are isolated in per-run scratch directories and Watch Mode scopes sub-squads per event (least common mechanism). The user-facing surface is a single /squad entry point, and a blocked action explains what was stopped and how to proceed (psychological acceptability). The package flow is one-directional: consumers pull assets and the package never reads from consumer environments, and the project runs no service and stores no user data (limited attack surface). Inputs are constrained by allowlists rather than denylists, through ValidateSet on script parameters, a fixed set of squad profiles, and an explicit untrusted-content boundary that treats all ingested external content as data to analyse and never as instructions to execute, refusing embedded authority changes such as "ignore previous instructions" or "set autonomy to full".

The primary developer has over eleven years of experience as a software developer and technical lead and works as a Partner Solution Architect at Microsoft, where secure development practice is part of the role. Because this project ships AI agent assets rather than a network service, the dominant error classes are those in the OWASP Top 10 for LLM Applications and the OWASP Agentic Security Initiative rather than the memory-safety and injection classes of the CWE Top 25, though the latter still apply to the build scripts. The relevant classes and their mitigations in this project are: prompt injection (LLM01), countered by an explicit untrusted-content boundary that processes all ingested external content as data to analyse or quote and never as instructions, and that refuses embedded authority changes such as "ignore previous instructions" or "set autonomy to full"; excessive agency and insecure output handling (LLM02, LLM06), countered by an impactful-action gate that halts any irreversible operation and resumes only on explicit human approval delivered through a separate channel, never on a timeout; supply-chain compromise (LLM03, CWE-1357), countered by pinning every third-party GitHub Action to a full commit SHA, pinning the upstream microsoft/hve-core dependency to a specific commit that only a guarded workflow may move, a resolved apm.lock.yaml, Dependabot updates, and OpenSSF Scorecard analysis; sensitive information disclosure (CWE-200), countered by a mandatory sanitisation checklist on any pull request proposing a shared learning, requiring removal of secrets, customer and individual names, internal URLs, and environment-specific paths, backed by GitHub secret scanning with push protection; CI script injection (CWE-94, CWE-78), countered by Zizmor static analysis of every workflow and by passing untrusted inputs through environment variables rather than interpolating them into shell blocks; path traversal (CWE-22), countered by consistent use of -LiteralPath in file operations; and missing authorization (CWE-862), countered by gates that persist in state.json and advance only on an authorised approval. Familiarity with these classes is further evidenced by the assessment tooling the project ships: security-review-llm.prompt.md drives owasp-llm and owasp-agentic assessments, and the package includes dedicated CVE analysis, dependency review, supply-chain review, and VEX generation agents.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project never retrieves a cryptographic hash, over HTTP or otherwise, so there is no hash whose integrity could depend on an unauthenticated channel. No file in the repository contains an http:// URL, and no build script or workflow invokes curl, wget, Invoke-WebRequest, Invoke-RestMethod, or any other direct download mechanism. All external content is fetched by established tools over HTTPS: git for source, the APM CLI for package dependencies, npm for the Copilot CLI, and the GitHub CLI for release automation. Integrity is enforced through immutable identifiers rather than separately published checksums. Every third-party GitHub Action is pinned to a full commit SHA, the upstream microsoft/hve-core dependency is pinned to a specific commit that only a guarded workflow is permitted to advance, apm.lock.yaml records the resolved dependency set, and build-time tooling such as Pester and PSScriptAnalyzer is installed at an exact -RequiredVersion.

The project has never had a vulnerability reported against it. There are no published GitHub security advisories, no open Dependabot alerts, and no known CVEs affecting the software this project produces. Dependabot alerts, Dependabot security updates, secret scanning, and push protection are enabled on the repository, and CodeQL, Zizmor, Checkov, and OpenSSF Scorecard run on every pull request with findings published to the GitHub Security tab. One code-scanning alert is currently open, a zizmor/artipacked warning raised on 2026-08-24 against a workflow. It is a static-analysis hygiene finding rather than a disclosed vulnerability, it carries no CVE or CVSS score, and it has been open for less than 60 days.

No critical or high-severity vulnerabilities have been reported against this project, and none are outstanding. The project is nonetheless set up to ship a fix quickly rather than relying on a promise to do so. SECURITY.md commits to acknowledging a report within 5 business days and providing a status update within 10, with the fix shipping in the next release and the advisory published once it is available. Releases are cut on demand when pending work is judged ready rather than on a fixed schedule, so a fix does not wait for a release window. CONTRIBUTING.md documents a hotfix procedure for the case where the default branch holds work that must not ship yet: a hotfix branch is cut from the last release tag, the fix is applied there, and Release Prep assembles and tags a patch release from that branch alone, leaving unshippable pending work untouched. The hotfix is then merged back so the fix survives the next release. Separately, every merge rebuilds a rolling pre-release tag within minutes, so a fix is installable for verification as soon as it lands, before a formal release is cut. Automated detection runs continuously through Dependabot alerts and security updates, CodeQL, Zizmor, Checkov, and OpenSSF Scorecard, with findings published to the GitHub Security tab.

The repository contains no credentials. All secrets consumed by CI are referenced exclusively through the GitHub Actions secrets context (GITHUB_TOKEN, COPILOT_GITHUB_TOKEN, HVE_SQUAD_PLUGIN_PUSH_TOKEN, SYNC_DEPS_TOKEN) and are stored as encrypted repository secrets, never as literals in tracked files. No private key material, keystore, or .env file is tracked. A pattern scan for GitHub tokens, AWS access keys, PEM private key blocks, Slack tokens, OpenAI keys, and JWTs found nothing across the 184 tracked files, and the same scan across the full 305-commit history on all branches likewise found nothing, so no credential was committed and later removed. GitHub secret scanning is enabled with push protection, currently reporting zero open alerts, which blocks a supported credential type from being pushed in the first place. The project runs no service and provisions no accounts, so there is no credential intended to limit public access that could be leaked.

Four FLOSS static analysis tools run in CI, all beyond compiler warnings and safe language modes. Checkov 3.2.533 scans infrastructure-as-code and workflow definitions and is configured as blocking, with any accepted finding requiring a justified inline checkov:skip. Zizmor 1.29.0 performs security analysis of GitHub Actions workflows, targeting supply-chain and privilege weaknesses such as credential persistence and template injection. CodeQL analyses the Python surface. PSScriptAnalyzer 1.25.0 analyses the PowerShell build scripts and test suites. All four publish SARIF results to the GitHub Security tab under distinct categories. Checkov and Zizmor are triggered on every pull request targeting the default branch with no path filter, and pull requests are the only route by which a change can reach that branch. Because a release is a tag cut from the head of the default branch, the tree that is released is exactly the tree those analysers have already passed, so static analysis is applied to every proposed release by construction rather than as a separate step that could be omitted. CodeQL additionally runs on a weekly schedule, and Zizmor on a weekly schedule, so newly published rules are applied to released code even when no change is proposed.

Three of the four static analysis tools are purpose-built vulnerability scanners rather than general-purpose quality linters. Zizmor exists specifically to find security vulnerabilities in GitHub Actions workflows, covering template injection, credential persistence, artifact poisoning, and excessive token permissions, which is the dominant vulnerability class for a project whose executable surface is largely CI automation. CodeQL applies semantic queries mapped to CWE categories such as injection, path traversal, and unsafe deserialization against the Python surface. Checkov scans infrastructure-as-code and workflow definitions for security misconfiguration and runs in blocking mode, with any accepted finding requiring a justified inline checkov:skip annotation. PSScriptAnalyzer additionally carries security-specific rules including PSAvoidUsingPlainTextForPassword, PSAvoidUsingConvertToSecureStringWithPlainText, PSAvoidUsingInvokeExpression, and PSUsePSCredentialType. All four publish SARIF to the GitHub Security tab under distinct categories. These tools find real issues rather than hypothetical ones: Zizmor currently reports an open artipacked finding against a workflow that persists a repository push token into the git configuration for the remainder of a job, which is being tracked for remediation.

No medium or higher severity exploitable vulnerability has been discovered by static analysis. CodeQL and Checkov currently report zero open alerts. PSScriptAnalyzer reports 22 findings, all Warning or Information severity and all code-quality in nature (naming conventions, comment-based help, ShouldProcess on internal helper functions), with no Error-severity findings and none carrying security impact; the CI gate blocks the build on Error severity. One Zizmor finding is open, artipacked, which reports that a checkout step in publish-plugin.yml persists a repository token into the git configuration for the remainder of the job. It was assessed and is not exploitable: that workflow is triggered solely by workflow_dispatch, which requires write access to the repository, and has no pull_request, pull_request_target, or fork-triggered path, so injecting a step to read the persisted credential requires privileges that already confer access to the token. Zizmor rates it Warning and GitHub assigns it no security severity level, placing it below the medium threshold. It is nonetheless tracked as a hardening item and will be addressed rather than dismissed. Findings that are accepted rather than fixed carry a justified inline annotation (# zizmor: ignore[...] or # checkov:skip=...) recording the reasoning, so no finding is silently suppressed.

Static analysis runs on every commit. Checkov and Zizmor are both triggered on every pull request targeting the default branch with no path filter, and pull requests are the only route by which a change can reach that branch, so no commit lands without being analysed regardless of which files it touches. Checkov additionally runs on every push to the default branch. CodeQL analyses the Python surface and PSScriptAnalyzer the PowerShell surface on any pull request or push touching those file types. Beyond change-triggered runs, three scheduled scans re-analyse the released code so that newly published rules are applied even when nothing has changed: Zizmor weekly on Mondays, OpenSSF Scorecard weekly on Tuesdays, and CodeQL weekly on Thursdays. All results are published to the GitHub Security tab under distinct categories, so a finding introduced by a rule update surfaces without a code change.

The project produces no software written in a memory-unsafe language. Its output is a package of markdown assets (agents, prompts, instructions, and skills) together with PowerShell 7 build scripts, Pester test suites, and YAML workflow definitions. There is no C, C++, or unsafe Rust in the repository and nothing is compiled to native code, so there is no memory-safety surface for a sanitizer or memory-error detector to examine. PowerShell runs on the .NET managed runtime, which provides memory safety by construction.

The test configuration deliberately enables more assertions than a normal run. The suites are assertion-based throughout, with 575 Pester assertions executing in the Tier 0 conformance run alone, and every case traces to a numbered entry in tests/squad-behavior-contract.md. Two switches exist specifically to widen assertion coverage during analysis. Tier 1's -Strict promotes consumption findings, which are advisory during a live run, to blocking during the self-check, on the reasoning that a mutation the contract merely mentions is a mutation it does not catch. Tier 0's -IncludeAdvisory enables additional assertion cases that are otherwise reported without gating. Tier 1 also ships mutation controls invoked with -SelfCheck, where each case breaks exactly one rule and requires the contract to detect it, which is the evidence that the assertions can fail rather than passing vacuously. All PowerShell scripts, modules, and test runners execute under Set-StrictMode -Version Latest with $ErrorActionPreference = 'Stop', turning uninitialised variable references, non-existent property access, and malformed method calls into terminating errors during analysis. Tier 0 additionally treats a run that produces zero tests as a failure, so a discovery error cannot be mistaken for success. None of this carries into what consumers receive: the shipped package is markdown assets with no runtime assertion machinery, so there is no production assertion cost or disclosure risk.

The project does not perform dynamic code analysis as this criterion defines it, consistent with the answer given for dynamic_analysis: it uses no fuzzer or scanner that varies inputs, and branch coverage is not instrumented, so the 80% alternative threshold cannot be demonstrated. No vulnerability has therefore been discovered by dynamic analysis, and none is outstanding. The project does run automated Pester test suites across three tiers, including live behavioural runs against fixture repositories, and these have found functional defects that were fixed and covered by regression cases, but they have surfaced no security vulnerability. Should dynamic analysis be introduced and a medium or higher severity exploitable vulnerability be confirmed, it would be handled under the process documented in SECURITY.md, which commits to acknowledgement within 5 business days, a status update within 10, and a fix in the next release, with a hotfix path documented in CONTRIBUTING.md for shipping a patch without releasing unrelated pending work.