Skip to content
Project VELAProject VELA

Owner setup checklist (GitHub settings)

These controls cannot be set by committing files — only the repository owner (@samuelvinay91) can toggle them in GitHub. Everything else in this revamp (LICENSE, SECURITY.md, CODEOWNERS, Dependabot config, PR/issue templates, CI workflows and their least-privilege permissions) is already committed. Do these once.

Highest ROI — do first (four toggles, ~5 minutes)

Settings → Code security (and Security tab):

  • Secret scanning — enable.
  • Push protection — enable (blocks commits containing detected secrets before they land).
  • Dependabot alerts — enable.
  • Dependabot security updates — enable (auto-PRs for known-CVE dependencies; complements the committed .github/dependabot.yml).
  • Private vulnerability reporting — enable (this is the intake channel SECURITY.md points to).
  • CodeQL — default setup — enable (baseline SAST). Do not treat a green CodeQL run as proof that VELA’s citation-integrity or MCP-boundary guarantees hold — those need the bespoke tests in docs/design/06-TEST-PLAN.md, not generic taint analysis.

Branch protection — default-branch ruleset

Settings → Rules → Rulesets → New branch ruleset, target main:

  • Block force pushes.
  • Block branch deletion.
  • Require a pull request before merging.
  • Require status checks to pass — add the CI jobs from .github/workflows/ci.yml and security.yml once they have run at least once (so the check names appear).
  • Require branches to be up to date before merging.
  • Leave “require review” OFF while there is a single maintainer (a review only you can give is self-bypass friction). Flip it ON against CODEOWNERS when a second maintainer joins.

Actions hardening

Settings → Actions → General → Workflow permissions:

  • Set the default GITHUB_TOKEN to read-only. (Workflows elevate per-job only where needed — already declared in the committed workflows.)

Repository metadata (About panel)

  • Description: e.g. “Agentic, advisory-only anomaly-investigation co-pilot for satellite operations — cited root-cause + recovery procedures, human-in-the-loop, air-gap capable.”
  • Topics: satellite-operations, ground-segment, anomaly-detection, mcp, langgraph.
  • Homepage / docs link (optional).

Set real contact addresses

  • Replace the placeholder security contact in SECURITY.md with a real intake address (or rely on Private Vulnerability Reporting above).

Enable Claude PR reviews (@claude + auto-review)

The workflows .github/workflows/claude.yml (responds to @claude mentions) and .github/workflows/claude-code-review.yml (auto-reviews non-draft PRs) are committed but dormant — they only run once you do all three of these:

  • Install the Claude GitHub App on this repo → https://github.com/apps/claude (or, in an interactive Claude Code terminal, run /install-github-app, which automates this plus the secret below — Anthropic-API users only).
  • Add the API key secret — Settings → Secrets and variables → Actions → New repository secret → name ANTHROPIC_API_KEY, value from https://console.anthropic.com. (To bill against a Claude Pro/Max subscription instead, run claude setup-token, add it as CLAUDE_CODE_OAUTH_TOKEN, and swap the commented line in both workflow files.)
  • Add the enable flag — Settings → Secrets and variables → Actions → Variables tab → New repository variable → name CLAUDE_ENABLED, value true. (This is the switch that wakes the workflows; until it is true, both jobs are skipped and produce no failing checks.)
  • Test: comment @claude on an issue or PR, or open a PR and watch the auto-review.

Notes: works on private repos; auto-review skips draft PRs (mention @claude to review a draft); each review costs API tokens + a few Actions minutes; --max-turns caps are set in the workflows.

Deliberately NOT enabled (anti-hobby-signal / premature)

  • Discussions — leave OFF (signals hobby-project to agency/enterprise buyers).
  • Sponsor / FUNDING button — leave OFF.

Trigger-gated (later — do NOT do now)

  • OIDC federation to a cloud provider — the first thing to set up when deployment automation begins, so no long-lived cloud key is ever created (irrelevant to the airgap path).
  • Tag / release protection ruleset — at the first customer-facing tagged release (critical for airgap appliance builds).
  • Required signed commits — once there is a team/release process to protect (breaks web-UI edits and Dependabot commits for a solo dev, so not before).