SZL Holdings · Doctrine v11 · Λ = Conjecture 1 (advisory, never "green"/theorem) · canonical a-11-oy.com

GitHub Surface Map

This document explains every file and directory under .github/ so contributors and reviewers know what each piece does and when to touch it.

---

Architecture

flowchart TD
  MONO[platform monorepo\npnpm + TypeScript]:::in --> RUNTIME[Ouroboros runtime]
  MONO --> FORMULAS[Lutar formulas]
  MONO --> ADAPTERS[Dual-witness adapters]
  RUNTIME --> COV{Covenant Policy\nhuman gate}
  COV --> PROOF[Cryptographic proof\nof every outcome]
  LEAN[(lutar-lean 749/14/163)] -.anchors.-> RUNTIME
  classDef in fill:#0B1F3A,color:#fff,stroke:#00D4FF;

See also: product surfaces · API spec. SLSA L1 honest; Doctrine v11.

Quick Reference

---

Workflows

Core CI (required for every PR)

Security

Build & Quality

Release & Deploy

Operations

---

Issue Templates

---

Dependency Update Policy

Dependabot is configured in dependabot.yml with the following schedule and limits:

All Dependabot PRs must pass the same required CI checks as any other PR.

Note — docs/github/packages/maven/pom.xml: This file is a documentation template for future Java/Kotlin consumers of the GitHub Packages registry (its header says "Copy this file to your package directory"). It is not an active production manifest. No Maven Dependabot entry is needed until an actual Java/Kotlin package is added to the repo.

---

Secret Scanning

Three complementary layers:

1. GitHub-native scanning and push protection: provider-known patterns are checked by GitHub, including before accepted pushes when push protection matches.
2. PR-time scan (security.yml → secret-scan): Gitleaks scans the PR's base-to-head commit range, then the project-specific scanner checks the current tree. A finding fails the Security Gate (blocking) fan-in job.
3. Default-branch and scheduled scan (security.yml → secret-scan): pushes to main, manual dispatches, and the Monday 03:00 UTC schedule scan reachable repository history with Gitleaks and check the current tree with the project-specific scanner.

Config lives in .gitleaks.toml. If you need to add an allowlist entry, document the reason inline and keep patterns as narrow as possible.

If a real leaked secret is discovered: do NOT rotate from a PR. File a high-priority follow-up task and add an entry to INCIDENT_RESPONSE.md under the "Suspected secret exposure" runbook.

---

Branch Protection Summary

See BRANCH_PROTECTION.md for the full GitHub UI configuration checklist. Required status checks for main:

• CI Gate
• Readiness Gate (smoke:product-mode)
• E2E Gate
• dependency-review
• analyze

The Lighthouse Gate (accessibility enforced) check is not currently listed as a required branch-protection context. When the workflow runs, only a completed successful matrix passes: accessibility assertions are hard failures and incomplete infrastructure fails closed. Performance, best-practices, and SEO assertions remain advisory warnings.