Repository setup preview

Choose a policy, review every file, then validate the default branch.

BoardReadyOps never writes repository contents with the production GitHub App. Review the exact configuration below, commit it through your normal branch protections, and run an OIDC-bound readiness probe.

No repository changes are made here

Least privilege is preserved

The App uses Metadata read, Pull requests read, Checks write, and Actions write. Contents access, organization permissions, and account permissions remain disabled. Any future assisted installation would require a separate, explicit opt-in to Contents write.

1. Select a policy preset

Preset contract v1. Switching presets appends a new revision; previous runs retain their original policy provenance.

Open-source hardware

Selected

Reproducible community releases with component traceability and release documentation.

Release mode: pilot
Fail threshold: high

Preview Open-source hardware

Prototype fabrication

Low-friction first-build checks with critical supply-chain and design safeguards.

Release mode: prototype
Fail threshold: high

Preview Prototype fabrication

Production release

Strict fabrication, supply-chain, manufacturing, and release evidence gates.

Release mode: production
Fail threshold: medium

Preview Production release

Contract design handoff

Auditable client handoff with complete evidence, traceability, and signed-off release gates.

Release mode: production
Fail threshold: medium

Preview Contract design handoff

2. Review the proposed repository files

These are the only repository-owned files required for the setup flow. Commit them through a reviewed pull request.

boardreadyops.yml

Selected preset: Open-source hardware

New or replace intentionally

Blocks: Enabled findings at high severity or above
Warns: Enabled findings below high severity
Ignores: Rules explicitly set to false in the preview

Open-source hardware boardreadyops.yml preview

version: 1
mode: enforce
releaseMode: pilot
projects:
  - path: .
fail-on: high
rules:
  bom.missing-mpn: true
  bom.compliance: true
  bom.lifecycle: true
  bom.eol-detection: true
  bom.unknown-lifecycle: true
  bom.identity-conflicts: true
  design.board-outline: true
  design.unique-references: true
  drc.kicad: true
  manufacturing.fab-notes: true
  manufacturing.layer-stackup: true
  manufacturing.drill-coverage: true
  release.revision-set: true
  release.changelog-present: true
  release.version-format: true
  release.tag-matches-revision: true
report:
  sarif: boardreadyops.sarif.json
  json: boardreadyops.findings.json
  markdown: boardreadyops.report.md
  html: boardreadyops.report.html

.github/workflows/readiness-runner.yml

Canonical v1 runner workflow, contract v1

Review before copying

Open the canonical v1 workflow source and review its pinned actions, permissions, inputs, and timeouts.
Copy it unchanged to .github/workflows/readiness-runner.yml on a feature branch.
Open a pull request and let your repository ruleset and required checks approve the change.

3. Validate workflow and configuration readiness

The control plane first inspects Actions and workflow metadata, then dispatches a short-lived probe owned by the target repository.

Confirm GitHub Actions is enabled and the workflow is active on the default branch.
Dispatch the setup probe with a 15-minute persisted deadline and idempotency key.
The workflow checks out its own default branch without persisted credentials and validates boardreadyops.ymlwith a pinned BoardReadyOps CLI.
The result is posted with GitHub Actions OIDC bound to the repository ID, workflow ref, branch ref, and probe ID.
The verified preset revision is snapshotted onto every newly accepted run and shown in run history.

Troubleshooting remains explicit

Missing workflow, disabled Actions, incompatible workflow metadata, missing configuration, invalid configuration, expired probe, stale probe, and dispatch failure are distinct persisted states with stable operator responses.

Permission review

No hidden organization or account access is requested.

Required GitHub App permissions and purposes
Scope	Permission	Purpose
Repository	Metadata: read	Bind the installation to the intended repository.
Repository	Pull requests: read	Associate runs and publication with authoritative pull requests.
Repository	Checks: write	Publish verified readiness conclusions.
Repository	Actions: write	Dispatch the repository-owned readiness workflow.
Repository	Contents: none	Repository files stay under contributor-controlled pull requests.
Organization / account	None	No organization-wide or user-account authority.