FDE BenchmarkPublic document reader
Available in sourcev0.1 · live public draft · official release pending

Canonical source view. This renders the bundled repository document as readable HTML. Source metadata remains in the repository, and relative document links remain inside this reader.

Production foundation

Record ID: LL-FDE-OPS-001
Version: 0.1.0
Verified: September 1, 2026
Status: partially implemented; noindex public-draft hosting is live, repository linkage and staffed operations are incomplete

1. Verified current state

Surface Verified fact Boundary
Initial local Git baseline At the start of this operations change, main pointed to 89309b5; no remote was configured The final candidate must use its own exact commit; a local commit is not an immutable public reference or backup
Proposed GitHub destination SamSnead85/lockedin-fde-benchmark, private At verification time the repository had not been created and the local GitHub CLI credential was not valid
Netlify account Team slug samsnead85; team name Sweilem stuff Account identity does not authorize benchmark publication
Netlify site ID 21114b18-5610-49bd-bd52-6d4a62b0c226; site name lockedin-fde-benchmark This is the existing target; a replacement site must not be created
Production origin https://fdebenchmark.org (canonical since 2026-09-03; benchmark.lockedinlabs.ai, fdebenchmark.com/.ai/.dev, and thefdebenchmark.com redirect permanently) Live, publicly reachable, and indexable as a public draft
Git linkage Netlify reports no repository, branch, base, or publish-directory binding Existing deployments are not continuous deployments from Git
Release posture Indexable on the canonical host with a canonical link on every prerendered route; official numeric output remains disabled No formal release, intake, verification, certification, or employment use

The Netlify identity and site binding were read from the authenticated API without changing site settings. Credential values are not stored in this repository.

2. Source controls now present

  • The active staging Git root is the parent workspace containing fde-benchmark, fde-evaluator, and fde-benchmark-platform. Root .github controls govern that repository, and they are the only copy. Nested fde-benchmark/.github and fde-evaluator/.github copies were removed on 2026-09-03: GitHub never executed them, they had already drifted from the root (Node 22 against Node 24, a shorter test list), and a copy that looks authoritative but does nothing is how someone edits the wrong file to fix CI and believes they did. If the public boundary is split into its own repository, generate its workflows from the root at that time.
  • Pull requests and pushes to main run source, schema, contract, experimental-scorer, research-study, reproducibility, public-site, rendered-browser, and accessibility gates.
  • Each successful public-site job retains the inspected build and a byte-level deployment-evidence record for 30 days.
  • Production deployment is manual, environment-gated, exact-commit-pinned, main-ancestry-checked, and restricted to the recorded Netlify site ID.
  • Every deployment reruns the complete gate, records build bytes, captures the Netlify receipt, and verifies 25 benchmark-only live routes plus noindex and security headers, two plain-text assets, a must-404 probe, and every reachable JavaScript chunk.
  • An hourly read-only monitor checks the live public-draft contract and retains receipts for 14 days.
  • Dependency-update configuration is isolated by package boundary.

These workflows are inert until a GitHub repository exists. GitHub artifact retention is operational convenience, not permanent scholarly preservation.

3. Activation sequence

3.1 Establish the private repository

An authorized operator must first authenticate and verify the destination:

gh auth login -h github.com
gh auth status
gh repo view SamSnead85/lockedin-fde-benchmark

If and only if the destination is approved and confirmed absent, run the creation command from the top level reported by git rev-parse --show-toplevel so all three current boundaries remain intact:

gh repo create SamSnead85/lockedin-fde-benchmark \
  --private \
  --source=. \
  --remote=origin \
  --push

Do not initialize a replacement repository, overwrite an existing remote, change visibility, or publish the repository without a separate decision.

3.2 Configure repository governance

Before accepting outside contributions or production deployments:

  1. Require multifactor authentication for maintainers.
  2. Protect main; require every job from the active LockedIn FDE benchmark quality workflow (source-integrity, contracts-and-measurement, evaluator, public-site, and assessment-platform) plus reviewed pull requests.
  3. Disable force pushes and branch deletion.
  4. Enable secret scanning, push protection, dependency alerts, and private vulnerability reporting where available.
  5. Create a protected GitHub environment named production-draft with required reviewers.
  6. Add NETLIFY_AUTH_TOKEN only as an environment secret, scoped to the existing site/team and rotated under the operating account.
  7. Test the private vulnerability route before changing the security-channel status.

No branch-protection rule or reporting channel is claimed operational until its configuration and test receipt exist.

3.3 Establish Git-based deployment

The reviewed workflow at the active Git root, .github/workflows/deploy-public-draft.yml, is the canonical production path and the only deploy workflow in the tree. It deploys only to site 21114b18-5610-49bd-bd52-6d4a62b0c226 and requires the phrase DEPLOY NOINDEX PUBLIC DRAFT.

Netlify may later be linked to the private repository for deploy previews. If linked, preserve the existing site and use:

  • repository: SamSnead85/lockedin-fde-benchmark;
  • production branch: main;
  • base directory: fde-benchmark/apps/public-site;
  • build command: npm run build;
  • publish directory: dist.

Automatic Netlify production publishing should remain disabled while the GitHub deployment workflow is authoritative. Two independent production writers create ambiguous release evidence and rollback state.

4. Deliberately unactivated controls

  • No GitHub repository or remote is claimed to exist.
  • No automatic production deployment runs on merge.
  • No issue form is activated because managed public contribution, licensing, private security reporting, and conduct reporting remain blocked.
  • No release tag, GitHub Release, DOI, archive deposit, or indexed publication is automated.
  • No external uptime vendor, status page, paging integration, named on-call owner, response-time commitment, or support SLA is claimed.

Activation requires the corresponding owner, authority, channel, and test evidence in the publication decision record and Live Versus Planned register.