PolicyChecks

The reponomics organization requires two-factor authentication for all members (GET /orgs/reponomics returns two_factor_requirement_enabled: true). The authoritative repository github.com/reponomics/PolicyChecks is owned by that organization, so every account able to read or modify sensitive resources must complete multi-factor authentication. The requirement covers outside collaborators as well as members.

A role must be assigned explicitly when a collaborator is added to the repository. Organization membership confers no elevated permission: the organization's base repository permission is read (GET /orgs/reponomics returns default_repository_permission: "read"), and because this repository is public, that base permission confers exactly the access an anonymous user already has. Every collaborator with write access holds an explicit grant.

The "protect-main" ruleset applies to the default branch with enforcement active and includes a pull_request rule, so commits cannot be applied directly to main and must arrive through a pull request. The ruleset defines no bypass actors, so no one can circumvent it, including repository admins and organization owners. It additionally enforces linear history, blocks non-fast-forward updates, and requires signed commits.

The "protect-main" ruleset includes a deletion rule applying to the default branch, so deleting main is blocked outright rather than merely confirmed. No actor can bypass the ruleset, including repository admins and organization owners.

No untrusted metadata reaches a shell in the project's GitHub Actions workflows. Branch names, commit messages, tags, pull-request titles, and author information are never interpolated into a run: block. Where a workflow needs the branch name, it reads the ${GITHUB_REF_NAME} environment variable inside double quotes rather than a ${{ }} expansion. The only ${{ }} expansions appearing inside run: blocks are github.server_url and github.repository, both GitHub-controlled values. The workflow that validates pull-request titles passes the title to a SHA-pinned action through the GitHub API and never into a shell. The Cloudflare Workers Builds deployment pipeline runs fixed literal commands with no metadata interpolation.

Neither of the project's two CI/CD pipelines exposes privileged credentials to unreviewed code. The only workflow triggered by pull_request_target, .github/workflows/semantic-pr.yml, checks out no pull-request code, runs no project code, and is limited to permissions: pull-requests: read. The only workflow holding privileged credentials, release-please.yml, is triggered exclusively by push to main and workflow_dispatch, so it never operates on an unreviewed code snapshot. ci.yml does execute pull-request code but references no secrets, and because the repository is public, fork pull-request tokens are downgraded to read-only and are given no secrets. The repository's default workflow token permission is read, and all actions are pinned to full-length commit SHAs. Production deployment runs through Cloudflare Workers Builds, documented in docs/operations.md; fork pull requests build there only after explicit admin approval, so untrusted code is reviewed by a collaborator before it can run with access to deploy credentials.

The project's official channels are the source repository at https://github.com/reponomics/PolicyChecks and the badge service at https://policychecks.reponomics.org, and both are reachable only over encrypted channels. A plain-HTTP request to the service returns 301 to the https:// origin, and responses carry strict-transport-security: max-age=86400. Badge endpoints return HTTP/2 200 over TLS with a valid certificate chain; the service root returns 404 by design, as the service exposes no landing page.

The project distributes through GitHub Releases (https://github.com/reponomics/PolicyChecks/releases), served exclusively over HTTPS, and through the hosted service, which is TLS-only with HTTP redirecting to HTTPS and HSTS set. The package is marked private: true in package.json and is not published to any registry. Every release tag commit carries a valid signature (verification.verified: true), and immutable releases are enabled (GET /repos/reponomics/PolicyChecks/immutable-releases returns enabled: true), so published release assets and tags cannot be altered after publication.

.gitignore excludes .env, .env.* (with an explicit !.env.example exception), and *.private-key.pem. .env.example contains blank placeholders and non-secret local defaults only. Secret scanning, push protection, non-provider pattern scanning, and validity checks are all enabled on the repository, so a secret is blocked at push time rather than merely detected afterward. Runtime secrets are held in the deployed Worker's settings rather than in build variables, and docs/operations.md documents credential storage.

The README documents what the service does, how it works, and how to use it (badge table, endpoint reference, examples); additional docs live in https://github.com/reponomics/PolicyChecks/tree/main/docs [documentation_basics]

The project has made releases, so this control applies. SUPPORT.md contains a "Service Issues" section directing defect reports to the GitHub issue tracker and enumerating what belongs there, states that public issues are preferred and why, routes repository-specific questions to support@reponomics.org, and directs security reports to SECURITY.md instead. CONTRIBUTING.md independently states that issues may be opened to report a bug. GitHub Issues is enabled (has_issues: true).

Both GitHub Issues and GitHub Discussions are enabled on the repository (GET /repos/reponomics/PolicyChecks returns has_issues: true and has_discussions: true). CONTRIBUTING.md directs contributors to open an issue to request a feature or report a bug, and to start a Discussion thread to engage other users on a topic; it further asks that proposed feature changes be raised in an issue first so they can be discussed publicly before implementation.

CONTRIBUTING.md at the repository root explains the contribution process: how to raise an issue or Discussion, the expectation that feature proposals are discussed before a PR, the types of contributions accepted (including project-specific criteria for proposing new badges), repository policies governing submissions (signed commits, PR-only changes to main, conventional-commit PR titles, running npm run check, resolving failing checks, including tests), and local development setup. https://github.com/reponomics/PolicyChecks/blob/main/CONTRIBUTING.md

The source code is licensed under the MIT license, which is OSI-approved and FSF free. Confirmed by the LICENSE file at the repository root, the "license": "MIT" field in package.json, and GitHub's own license detection (GET /repos/reponomics/PolicyChecks returns license.spdx_id: MIT).

The released software assets carry no separate license. The releases publish no separate assets, so the only released artifacts are the source archives generated for each tag, governed by the same MIT license as the source code. Those archives contain LICENSE at their root. MIT is OSI-approved and FSF free.

The MIT license text is maintained in the LICENSE file at the root of the repository: https://github.com/reponomics/PolicyChecks/blob/main/LICENSE. The project has a single repository, so there is no additional repository requiring its own license file.

The releases publish no separate assets, so the released software assets are the source archives generated for each tag. Those archives include the MIT license at the archive root; nothing in the repository's export configuration removes it.

The source repository is publicly readable at the static URL https://github.com/reponomics/PolicyChecks. GET /repos/reponomics/PolicyChecks returns private: false, visibility: "public", archived: false. It is hosted on GitHub.

The full git history is publicly readable and records the author name, email, and date of every commit. History rewriting on the primary branch is blocked: the "protect-main" ruleset enforces required_linear_history, non_fast_forward, and required_signatures with no bypass actors, so force-pushes and rewrites to main are rejected. Because linear history is required, merges are limited to squash and rebase. Squash merging collapses a branch's individual commits, but authorship is preserved through it, and the history on main attributes work to both maintainers and external contributors.

npm supports dependency manifests, and the repository contains package.json enumerating all direct language dependencies, alongside package-lock.json pinning the fully resolved transitive tree. CONTRIBUTING.md directs contributors to install from the lockfile with npm ci and to use npm install only when intentionally updating dependencies and committing the resulting lockfile change.

PolicyChecks is a single codebase in a single repository - the Cloudflare worker entry point lives in-repo at cloudflare/policychecks-worker.ts. No subproject repository is produced or compiled into a release, so there is no list of constituent codebases to document.

No generated executable artifact is tracked; file --mime over every tracked file returns no executables. Build and coverage outputs are excluded from version control: .gitignore covers dist/, build/, out/, coverage/, and node_modules/, and none of those paths is tracked. Exactly one tracked file carries the executable bit, .husky/pre-commit, a short hand-written shell hook rather than a generated artifact. The worker is generated at build time by npm run build (tsconfig.build.json).

The only binary files tracked are PNG images under docs/assets/ - project banners and documentation screenshots. Graphical images are outside this control's scope. No executable application binaries, library files, or comparable unreviewable artifacts are tracked.

SECURITY.md at the repository root publishes the project's security contacts: a GitHub Private Vulnerability Reporting link (https://github.com/reponomics/PolicyChecks/security/advisories/new) as the primary channel and security@reponomics.org as a fallback, together with a stated 14-day maximum for follow-up. SUPPORT.md cross-references it and explicitly directs security issues away from public issues and the general support address.