Repository navigation
software-factory: record where it departs from the org standards, and exempt it from the matching audit findings #1321
Description
petry-projects/software-factory is the clean rebuild of the agent fleet. It follows these standards except in the places below. ci-standards.md asks that a departure be recorded here by an issue "rather than diverging silently", so this is that record.
The repo's own record is docs/decisions/0014-where-this-repo-departs-from-the-orgs-standards.md, added by the pull request "Context for the Factory's authors: lessons, standards, decisions and the checks that hold them" (petry-projects/software-factory pull request 6). It is marked proposed until that pull request merges. The standards were read at commit 9e2daad.
What it adopts as written
- The secrets baseline at the top of
.gitignore, held by its hash. - The secret-scan job from
push-protection.md, "Required CI job", in.github/workflows/ci.yml, with.gitleaks.toml. - Action pinning with the version beside the hash, and channel tags for the org's own reusable workflows (
ci-standards.md, "Action Pinning Policy" and "Exception: Internal Reusable Workflow References"). AGENTS.mdreferencing the org's,CLAUDE.mdimportingAGENTS.md, and the README sections "Local Development Commands" and "Required Environment Variables".
Where it departs, and why
| Standard | What software-factory does | Why |
|---|---|---|
ci-standards.md, "1. CI Pipeline (ci.yml)": lint, format, type check and coverage stages; the Python instructions, "Testing (pytest)" |
One required check, factory / verify: make verify and a mutation check, on unittest |
The repo installs nothing: its required check runs only what is in the commit. Each of those tools is an install. The mutation check stands where a coverage threshold would |
ci-standards.md, "3. SonarCloud Analysis (sonarcloud.yml)" |
No SonarCloud workflow of its own | The template needs a step that may fail, a runner named -latest and a download |
ci-standards.md, "Required Workflows": dev-lead, pr-review-mention, pr-auto-review, initiative-driver, feature-ideation, dependabot-automerge |
None of them | They are the fleet this repo replaces. Each needs a personal access token or every secret, one runs on pull_request_target, and one gives the model's job write access |
codeowners-standard.md, "Rule": org-leads first on every line, no individual |
The Maintainer alone owns the Factory's own rules | org-leads holds the machine user that submits the Factory's approvals, so the Factory could approve a change to what governs it |
github-settings.md, "code-quality — Required Checks Ruleset (All Repositories)" |
Not applied until each of its four checks exists there | Applied first, it blocks every pull request |
ci-standards.md, "1. CI Pipeline (ci.yml)": a concurrency group |
None on the required check | A group evicts a waiting run |
copilot-instructions-standard.md, "Creating a Repo-Level copilot-instructions.md"; the setup-steps workflow |
Neither | A second always-loaded file is a second copy of the rules; nothing needs setting up |
The org's AGENTS.md, "BMAD Method — Spec-Driven Development" |
The design lives under docs/prd/ and docs/architecture/ |
BMAD is installed by a download |
The org's AGENTS.md, "Thread Resolution Policy": agents resolve every thread, a person's included |
A person's thread is closed by that person | An agent once resolved the threads that were holding it |
Taken up later and not departed from: a Dependabot entry for workflow actions, the agent-shield and dependency-audit callers, CodeQL default setup, the pr-quality ruleset, the repo settings and labels.
What is asked
- That the compliance audit not file the findings that match the rows above for
petry-projects/software-factory, so that the fleet's own agent does not open pull requests adding those workflows to it. - That the exception be noted beside each standard it touches, or in one place the audit reads.
- A ruling on anything in the table the org would rather the repo adopt.
One thing the org may want to know
Measured against software-factory's workflow rules, each of the ten required workflow templates under standards/workflows/ breaks at least one. The commonest: a first-party reusable not at a channel tag or an action not at a commit (pin), a personal access token or secrets: inherit (token), and no merge_group trigger on a workflow that runs on pull requests (queue). The templates ci.yml and sonarcloud.yml lack merge_group although SonarCloud is a required check.
Activity
don-petry commentedon Oct 11, 2026
One addition, found when the secret-scan job first ran in software-factory.
SonarCloud fails a pull request that adds the job from
push-protection.md, "Required CI job", as written. The finding is rule S6506 on the download line:wget -q "${url}" -O /tmp/gitleaks.tar.gzfollows a redirect without being held to HTTPS. The checksum on the next line would catch a swapped program, but the quality gate does not weigh that, so the template and theSonarCloudrequired check cannot both pass on new code.software-factory now downloads with
curl -sSfL --proto '=https' --proto-redir '=https' -o /tmp/gitleaks.tar.gz "${url}", on the Maintainer's ruling, and is otherwise the org's text. If the org takes the same line into the template inpush-protection.mdandstandards/workflows/ci.yml, the two agree again.don-petry commentedon Oct 14, 2026
One row withdrawn. On the Maintainer's ruling of 2026-10-14, software-factory's code owners follow the org's standard: its
.github/CODEOWNERSis the org's own file, copied word for word, and a check in that repo holds it to that text. The row "The team org-leads first on every line of the code owners file, and no individual" is no longer a departure, and is out of its decision record.