docs: name the fleet sync and the central CI in plain words instead of the platform repository

.github/actionlint.yaml

@@ -1,5 +1,5 @@
 # Repo-owned actionlint configuration. Generated once by
-# Vivswan/repo-platform and never overwritten by template
+# the fleet sync and never overwritten by a later
 # sync, so add this repository's own ignores freely.
 
 paths:

.github/scripts/coverage-data.yml

@@ -232,7 +232,7 @@ outOfScope:
     - >-
       Repo-content-borne configuration (CODEOWNERS, dependabot.yml, workflow files, issue/PR
       templates, FUNDING.yml, .gitattributes): These are versioned files in the repository tree,
-      managed by commits/PRs (e.g. by the repo-platform sync), not by the settings REST API.
+      managed by commits/PRs (e.g. by the fleet sync), not by the settings REST API.
       Writing repo content is a different tool's job.
     - >-
       Self-hosted runners (repo-level registration, labels): Operational infrastructure lifecycle:

.github/settings.yml

@@ -1,8 +1,8 @@
 ---
 # This repository's OWN settings. Two writers are built to apply the SAME six-layer
-# merge of this file with the fleet layers: Vivswan/repo-platform's central
+# merge of this file with the fleet layers: the fleet's central
 # settings-repos heal, and this repo's own apply-settings.yml, the hook for
-# ci.yml's post-green slot: it renders the merge with repo-platform's
+# ci.yml's post-green slot: it renders the merge with the fleet's
 # scripts and applies it with the action at HEAD (dogfooding,
 # APPLY_SETTING_TOKEN).
 # Rendered once, repo-owned: template sync never rewrites it. Fleet defaults

.github/workflows/apply-settings.yml

@@ -1,11 +1,12 @@
 # The most direct consumer of this action is this repository itself: its
 # settings are applied by the CURRENT code (uses: ./), so a regression here
 # bites us before it bites anyone else. The document it applies is the
-# SAME six-layer merge Vivswan/repo-platform computes for this repository
+# SAME six-layer merge the fleet's central settings run computes for this
+# repository
 # (the settings-sync module: fleet baseline, module layers, this repo's
-# .github/settings.yml, the fleet override), rendered with repo-platform's
+# .github/settings.yml, the fleet override), rendered with the platform's
 # own scripts, so this writer and the central heal converge on one
-# document: each renders from a green repo-platform commit, so two runs
+# document: each renders from a green platform commit, so two runs
 # can differ only by a platform revision, and the next heal settles it.
 # Applying this repo's partial settings.yml alone would delete every fleet
 # label the merged roster carries. Needs APPLY_SETTING_TOKEN
@@ -14,7 +15,7 @@
 # Called from post-green.yml, the repo-owned hook ci.yml runs after the
 # all-green gate and before release (the judged commit as `sha`, secrets:
 # inherit): that call is the only write trigger, so settings never come from
-# a commit the gate has not passed. The weekly heal is repo-platform's
+# a commit the gate has not passed. The weekly heal is the fleet's
 # central settings run; a dispatch only reports drift.
 
 name: Apply Settings
@@ -56,7 +57,7 @@ jobs:
             echo "proceed=true" >> "$GITHUB_OUTPUT"
           else
             echo "::notice::APPLY_SETTING_TOKEN is not set; self-apply skipped. Add a fine-grained PAT secret" \
-              "(Administration + Issues, read and write) to enable it. Vivswan/repo-platform's central" \
+              "(Administration + Issues, read and write) to enable it. The fleet's central" \
               "settings run applies this repository's settings either way."
             echo "proceed=false" >> "$GITHUB_OUTPUT"
           fi
@@ -72,14 +73,14 @@ jobs:
         with:
           ref: ${{ github.event_name == 'workflow_dispatch' && github.event.repository.default_branch || inputs.sha }}
 
-      # repo-platform's `build` branch is the green-gated delivery ref the
+      # The platform's `build` branch is the green-gated delivery ref the
       # fleet pins, but its tree carries only workflow files, never the
       # scripts. Its tip commit message carries a provenance stamp naming
       # the green main commit it was composed from (the same
       # `source: .../commit/<sha>` line reusable-apply-settings.yml
       # parses), so the scripts are checked out THERE: the exact commit
       # CI vouched for. A tip without a stamp fails closed.
-      - name: Resolve the repo-platform scripts commit
+      - name: Resolve the platform scripts commit
         id: scripts
         if: steps.token.outputs.proceed == 'true'
         env:
@@ -88,12 +89,12 @@ jobs:
           message="$(gh api repos/Vivswan/repo-platform/commits/build --jq '.commit.message')"
           stamp="$(printf '%s\n' "$message" | sed -n -E 's|^source: .*/commit/([0-9a-f]{40})$|\1|p' | head -n 1)"
           if [ -z "$stamp" ]; then
-            echo "::error::refusing to run repo-platform scripts: the build tip carries no provenance stamp."
+            echo "::error::refusing to run the platform scripts: the build tip carries no provenance stamp."
             exit 1
           fi
           echo "ref=$stamp" >> "$GITHUB_OUTPUT"
 
-      - name: Check out repo-platform
+      - name: Check out the platform scripts
         if: steps.token.outputs.proceed == 'true'
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
@@ -108,7 +109,7 @@ jobs:
         with:
           bun-version-file: platform/.bun-version
 
-      - name: Install repo-platform script dependencies
+      - name: Install the platform script dependencies
         if: steps.token.outputs.proceed == 'true'
         working-directory: platform
         run: bun install --frozen-lockfile --silent

.github/workflows/auto-format.yml

@@ -1,7 +1,7 @@
 # Repo-owned auto-format: label a pull request `fix-lint` (the label ships
 # with the template's settings.yml) and this workflow pushes a formatting
 # commit to the PR branch, then removes the label. Generated once by
-# Vivswan/repo-platform and never overwritten by template
+# the fleet sync and never overwritten by a later
 # sync: adjust the format commands to this repository's tooling.
 
 name: Auto Format

.github/workflows/copilot-setup-steps.yml

@@ -2,7 +2,7 @@
 # job below (it MUST be named copilot-setup-steps) to prepare its
 # development environment before working on this repository. Triggered on
 # edits to itself so changes are validated in CI. Generated once by
-# Vivswan/repo-platform and never overwritten by template
+# the fleet sync and never overwritten by a later
 # sync: add whatever setup the agent needs (dependencies, generated files,
 # environment checks).
 

.github/workflows/nightly-fuzz.yml

@@ -3,8 +3,8 @@
 # oracle, and runs the freshly built bundle against the mock. Failing iterations
 # dump artifact directories with contract-shaped report.md files (title +
 # replay block), which the fuzz-issue steps below turn into one deduplicated
-# tracking issue. Repo-owned: generated once by Vivswan/repo-platform and
-# never overwritten by template sync.
+# tracking issue. Repo-owned: generated once by the fleet sync and
+# never overwritten by a later sync.
 name: Nightly Fuzz
 
 on:

.github/workflows/nightly.yml

@@ -1,13 +1,13 @@
-# Nightly upstream-freshness probes. Generated from the repo-platform nightly
-# starter and never overwritten by template sync. The checks job re-cuts the
+# Nightly upstream-freshness probes. Generated from the fleet sync's nightly
+# starter and never overwritten by a later sync. The checks job re-cuts the
 # trimmed OpenAPI spec from upstream HEAD (a path-level staleness check) and
 # typechecks against the latest @octokit/types, so pinned-dependency staleness
 # fails a night instead of surprising the next manual bump; the float-canary
 # job re-resolves the lockfile from scratch the way the Dependabot lockfile
 # workflow does, so a breaking upstream release fails a night instead of
 # reddening every open Dependabot PR; the report job below files or updates
 # one label-deduplicated tracking issue on a red night and closes it on a
-# green one (see repo-platform's docs/nightly.md).
+# green one (see the platform repository's docs/nightly.md).
 name: Nightly
 
 on:

.github/workflows/post-green.yml

@@ -1,5 +1,5 @@
-# Repo-owned: generated once by Vivswan/repo-platform, never overwritten by
-# sync. ci.yml calls it after the all-green gate, before the release, with
+# Repo-owned: generated once by the fleet sync, never overwritten by a
+# later sync. ci.yml calls it after the all-green gate, before the release, with
 # the judged sha. Pending runs coalesce (ci.yml's concurrency group), so
 # jobs here reconcile current state and stay idempotent.
 

.gitleaks.toml

@@ -1,6 +1,6 @@
 # Repo-owned gitleaks config, read by the CI gitleaks job (and local
-# `gitleaks git` runs). Seeded once by repo-platform's template and never
-# overwritten by sync, so allowlists added here survive updates.
+# `gitleaks git` runs). Seeded once by the fleet sync's template and never
+# overwritten by a later sync, so allowlists added here survive updates.
 # [extend] pulls in gitleaks' default ruleset - without it, this file
 # would REPLACE the defaults and disable every stock rule.
 # minVersion is honored only by binaries new enough to know it (an older

.repo-platform.yml

@@ -1,4 +1,4 @@
-# Generated once by repo-platform and repo-owned from then on: the sync reads this file and never rewrites it.
+# Generated once by the fleet sync and repo-owned from then on: the sync reads this file and never rewrites it.
 modules:
   - bun
   - docs-site

AGENTS.md

@@ -40,4 +40,4 @@ GitHub Settings as Code: GitHub Action applying declarative repository settings:
 - Scenarios must run green via `bun run test:e2e` before they land. The diff-aware selector (`.github/scripts/changed-sections.ts`) maps a PR's changed files to the sections its e2e smoke job runs: a path's first segment under `src/sections/` selects its section (`src/sections/<key>/...` selects `<key>`, whatever the file), `shared/` files fan out to the sections that import them (derived from the import graph, so a new import edge selects its section automatically), and `registry.ts` plus the cross-cutting prefixes (`contract/`, the engine, the schema, the harness, the CI scripts) select every section. An unrecognized `src/sections/` path throws, so a new file cannot silently skip the smoke job.
 - SCOPE CONVENTION: a flat `src/sections/<key>/` directory means repository scope, permanently. Org/user settings arrive as sibling scope directories (`src/sections/org/<key>/`) with their own document/SECTION_KEYS/registry triples, composed from their own slices the same way. Bare `${section}.${role}` keys stay repo-scope and other scopes get scope-prefixed keys - the ":" reservation assert in `src/sections/registry.ts` documents this - and the future `SectionPermission` union must keep today's `{repo: [...], org?: ...}` object literal valid verbatim as its repo arm.
 - `src/upstream-gaps/` holds one file per GitHub feature an upstream artifact lags: octokit-kind gaps (routes @octokit/types does not type yet; a tripwire fails typecheck naming the file when octokit catches up) and spec-only gaps (octokit has the types, the pinned OpenAPI descriptor lacks the paths). The auto-fix workflow graduates octokit-kind gaps automatically (delete or rewrite-to-spec-only); spec-only gaps retire by hand when UPSTREAM_REF moves. index.ts is GENERATED (bun .github/scripts/gen-gaps-index.ts); mechanics in gap.ts.
-- The `release` job in ci.yml is deliberately NOT in all-green's `needs`: it runs downstream of the gate (ci.yml calls the fleet's release workflow, Vivswan/repo-platform's fleet-release.yml, via workflow_call), so releases and release-PR refreshes only happen on a green main. Do not add it to the needs list. The packaged-ref scheme rides the managed pipeline through four repo-owned pieces: `post-green.yml` appends a green main commit's packaged commit (its tree minus workflows plus the built bundle, its source in a Source trailer; parented on the previous chain tip, or a root while the chain does not exist yet) to the `build` branch when its token can push, the release hook appends the release's when post-green did not, and both point the `latest` tag at the chain commit of the newest main source; `update-release.yml` (the hook the managed pipeline calls on a release cut) finds the `build` commit whose source is the merge commit (appending it when post-green could not), mints the `vX.Y.Z` tag there, and reconciles `latest` to the chain commit of the newest main source - `release-please-config.json` pins the fleet's `force-tag-creation` off, so no tag ever lands on main - while `checks.yml`'s boundary-check job and the anchor in `update-release-pr.yml` (the release-PR hook the managed pipeline calls on every release-PR refresh) keep `last-release-sha` fresh (version tags live off main, so release-please's boundary is recorded config, not a tag lookup). The git topology lives in `.github/scripts/release-pipeline.ts`, unit-tested in test/scripts/release-pipeline.test.ts.
+- The `release` job in ci.yml is deliberately NOT in all-green's `needs`: it runs downstream of the gate (ci.yml calls the fleet's release workflow, fleet-release.yml, via workflow_call), so releases and release-PR refreshes only happen on a green main. Do not add it to the needs list. The packaged-ref scheme rides the managed pipeline through four repo-owned pieces: `post-green.yml` appends a green main commit's packaged commit (its tree minus workflows plus the built bundle, its source in a Source trailer; parented on the previous chain tip, or a root while the chain does not exist yet) to the `build` branch when its token can push, the release hook appends the release's when post-green did not, and both point the `latest` tag at the chain commit of the newest main source; `update-release.yml` (the hook the managed pipeline calls on a release cut) finds the `build` commit whose source is the merge commit (appending it when post-green could not), mints the `vX.Y.Z` tag there, and reconciles `latest` to the chain commit of the newest main source - `release-please-config.json` pins the fleet's `force-tag-creation` off, so no tag ever lands on main - while `checks.yml`'s boundary-check job and the anchor in `update-release-pr.yml` (the release-PR hook the managed pipeline calls on every release-PR refresh) keep `last-release-sha` fresh (version tags live off main, so release-please's boundary is recorded config, not a tag lookup). The git topology lives in `.github/scripts/release-pipeline.ts`, unit-tested in test/scripts/release-pipeline.test.ts.

CONTRIBUTING.md

@@ -25,7 +25,7 @@ PR CI runs a diff-aware subset, scoped to the sections a pull request changed. T
 
 ## Releases
 
-The release leg is ci.yml calling Vivswan/repo-platform's fleet-release.yml via workflow_call, downstream of the `all-green` gate and of post-green.yml, so releases and release-PR refreshes only happen from a green main. release-please does version math, the changelog, the manifest and version pins, and the release PR; merging that PR has it cut the release as a draft with no tag.
+The release leg is ci.yml calling the fleet's release workflow, fleet-release.yml, via workflow_call, downstream of the `all-green` gate and of post-green.yml, so releases and release-PR refreshes only happen from a green main. release-please does version math, the changelog, the manifest and version pins, and the release PR; merging that PR has it cut the release as a draft with no tag.
 
 Every release ref a `uses:` pin can name from now on - the `vX.Y.Z` tags, the moving major, and the `latest` tag - points at a packaged commit on the `build` branch: the source tree without its workflows, plus the built bundle, its source named in a Source trailer (the tags cut before that branch existed, v2.0.0 and earlier, stay on main commits from when main committed the bundle). post-green.yml appends one for each green main commit when its token can push, and the repo-owned update-release.yml hook appends the release's when post-green could not.
 

COVERAGE.md

@@ -94,7 +94,7 @@ Repo-scoped settings the GitHub UI offers but no REST or GraphQL endpoint can wr
 - Projects: Classic repo projects are sunset; Projects v2 are user/org-owned GraphQL objects merely linked to repos. The repo-level has_projects flag rides the repository PATCH passthrough.
 - Pinned issues: GraphQL pinIssue/unpinIssue exist (max 3 pins, readable back via Repository.pinnedIssues), but a pin's value is an issue number - per-repo work-item content, not repository configuration - and re-asserting pins from YAML would fight ongoing triage. Named here because the surface is real and settings-adjacent; deliberately unmanaged, unlike pinned environments, whose values are environment names the settings file already owns (the environments section's `pinned` key).
 - Releases: Releases are content/artifacts, not configuration. The one release-policy setting with a REST surface, immutable releases, is supported via the repository section's enable_immutable_releases toggle (see the Supported table); anything else GitHub ships as a field on PATCH /repos gets picked up by the repository passthrough automatically.
-- Repo-content-borne configuration (CODEOWNERS, dependabot.yml, workflow files, issue/PR templates, FUNDING.yml, .gitattributes): These are versioned files in the repository tree, managed by commits/PRs (e.g. by the repo-platform sync), not by the settings REST API. Writing repo content is a different tool's job.
+- Repo-content-borne configuration (CODEOWNERS, dependabot.yml, workflow files, issue/PR templates, FUNDING.yml, .gitattributes): These are versioned files in the repository tree, managed by commits/PRs (e.g. by the fleet sync), not by the settings REST API. Writing repo content is a different tool's job.
 - Self-hosted runners (repo-level registration, labels): Operational infrastructure lifecycle: registration requires short-lived tokens and a live agent process; there is no meaningful declarative desired-state to reconcile from a YAML file.
 - Imperative repository operations (transfer, archive-via-migration, fork creation, branch create/rename, workflow/repository dispatch, cache purges, alert triage for code scanning / secret scanning / Dependabot alerts, issues and PRs): One-shot actions or work items, not settings; running them repeatedly from declarative state is meaningless or destructive. (The archived boolean itself IS supported via repository PATCH.)
 - Codespaces user/org configuration (user secrets, machine-type policies, org access controls): User- and org-scoped; the only repo-scoped Codespaces surface is repository Codespaces secrets, supported via the `codespaces_secrets` section.

test/docs/ci-workflow.test.ts

@@ -20,7 +20,7 @@ const ROOT = join(import.meta.dir, "..", "..");
 
 // Deliberately outside the gate: a red run flags template-convention drift
 // that the next sync PR heals, and must not block unrelated merges. Mirrors
-// repo-platform's validator (see its docs/all-green.md).
+// the central CI's validator (see the platform repository's docs/all-green.md).
 const INFORMATIONAL = new Set(["validate-template"]);
 
 interface Workflow {
@@ -80,7 +80,7 @@ function expectReleasePrefixes(wf: Workflow): void {
 describe("ci.yml release PR branch spelling", () => {
   // ci.yml is template-managed and carries no head_ref condition today; a sync
   // PR that brings one spelling the release PR branch namespace differently
-  // fails here, and the fix routes to Vivswan/repo-platform, not this file.
+  // fails here, and the fix routes to the platform repository, not this file.
   test("every startsWith(github.head_ref, ...) prefix is RELEASE_PR_BRANCH_PREFIX", () => {
     const text = readFileSync(join(ROOT, ".github", "workflows", "ci.yml"), "utf8");
     expectReleasePrefixes(parseYaml(text) as Workflow);