Security and architecture before merge

The Hyperoru architecture-check command checks security and architectural change in a native GitHub, GitLab, or Bitbucket job. It reviews the full commit, waits for the durable workflow, then verifies the security verdict and architecture comparison for that exact review. The installer vendors a reviewed copy into your repository, so a registry outage or unpublished package cannot change the gate that protects a merge.

./actions/install-architecture-check.sh github /path/to/repository
./actions/install-architecture-check.sh gitlab /path/to/repository
./actions/install-architecture-check.sh bitbucket /path/to/repository

The action fails closed if the returned gate belongs to another concurrent audit. It never asks an agent whether a pull request should merge.

GitHub

Create a workspace API token with audits:read and audits:write, save it as HYPERORU_API_TOKEN, and add the workspace and repository UUIDs as GitHub variables.

name: Hyperoru architecture gate

on:
  pull_request:

permissions:
  contents: read

jobs:
  architecture:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the pull-request commit
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Evaluate the Hyperoru architecture gate
        uses: ./.github/actions/hyperoru-architecture-check
        with:
          api-token: ${{ secrets.HYPERORU_API_TOKEN }}
          workspace-id: ${{ vars.HYPERORU_WORKSPACE_ID }}
          repository-id: ${{ vars.HYPERORU_REPOSITORY_ID }}
          commit-sha: ${{ github.event.pull_request.head.sha }}
          security-threshold: high

Security gate

All 12 required repository checks must complete successfully. A review with failed checks, missing observations, unrecognized severities, or coverage gaps cannot pass. The default high threshold blocks high and critical findings observed at that commit. Use critical, high, medium, low, or info to choose the minimum blocking severity.

The result uses observed severity from the review. Changing triage state or marking roadmap work done does not make that commit safe. Run another review after fixing the source. GitHub exposes security-outcome and security-blocking-count outputs; every provider receives a failing exit code for blocked or incomplete security.

Architecture gate

The job summary includes source coverage, the policy reasons, change consequences, owner hints, affected graph paths, and an explainable impact score. The score is decomposed into repository criticality, reachability, data sensitivity, trust-boundary exposure, and uncertainty; every component retains graph and evidence references. Configure the required check in the repository's branch protection after its first run.

GitLab

Connect the GitLab account, explicitly add the project to audit scope, and save a token with audits:read and audits:write as a masked, protected HYPERORU_API_TOKEN CI/CD variable. Add the workspace and Hyperoru repository UUIDs as HYPERORU_WORKSPACE_ID and HYPERORU_REPOSITORY_ID.

hyperoru:architecture:
  image: node:22-alpine
  stage: test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  variables:
    HYPERORU_COMMIT_SHA: $CI_COMMIT_SHA
  script:
    - node .hyperoru/architecture-check.cjs
  allow_failure: false

GitLab turns the job exit code into merge-request pipeline status. The Hyperoru token can start and read audits; it cannot push commits, approve a merge request, or change branch rules.

Bitbucket

Connect the Bitbucket workspace, explicitly select the repository, and add the three HYPERORU_* values as secured repository variables.

image: node:22-alpine

pipelines:
  pull-requests:
    "**":
      - step:
          name: Hyperoru architecture gate
          script:
            - export HYPERORU_COMMIT_SHA="$BITBUCKET_COMMIT"
            - node .hyperoru/architecture-check.cjs

Bitbucket publishes the step result to the pull request. As with GitHub and GitLab, the command compares the persisted audit ID before enforcing the gate, so a concurrent run cannot silently substitute another result.

CLI inputs

The provider-neutral command accepts HYPERORU_API_TOKEN, HYPERORU_WORKSPACE_ID, HYPERORU_REPOSITORY_ID, and the CI provider's full commit SHA. Optional variables are HYPERORU_API_URL, HYPERORU_DEEP_REVIEW, HYPERORU_TIMEOUT_SECONDS, HYPERORU_POLL_INTERVAL_SECONDS, HYPERORU_FAIL_ON, and HYPERORU_SECURITY_THRESHOLD (default: high).

HYPERORU_FAIL_ON changes architecture policy only. It cannot bypass a blocked or incomplete security verdict. Install the check in your own provider and make its successful job status a branch requirement; connecting a repository alone does not change branch protection.