Onboard FS.GG.Net to coordination-kit via the FS.GG.Kit package (FS-GG/.github#1291)

.config/dotnet-tools.json

@@ -0,0 +1,18 @@
+{
+  "version": 1,
+  "isRoot": true,
+  "tools": {
+    "fake-cli": {
+      "version": "6.1.4",
+      "commands": [
+        "fake"
+      ]
+    },
+    "fs.gg.coord.cli": {
+      "version": "0.7.0",
+      "commands": [
+        "fsgg-coord-engine"
+      ]
+    }
+  }
+}

.config/kit/FS.GG.Kit.receiver.proj

@@ -0,0 +1,46 @@
+<Project Sdk="Microsoft.NET.Sdk">
+
+  <!--
+    FS.GG.Kit receiver (ADR-0062, .github#1262 / .github#1291). This repo is a `coordination-kit`
+    receiver: it holds the shared coordination skills, the `fsgg-coord` client, and the engine tool
+    manifest on disk. Net was rostered for the kit at creation but never wired for it (.github#1291);
+    it is onboarded DIRECTLY onto package delivery — it REFERENCES the versioned `FS.GG.Kit` package
+    and MATERIALIZES that kit onto disk from its pin, skipping the byte-copy step entirely. A hub
+    change reaches this repo as an ordinary Renovate bump of the pin (in Directory.Packages.props), and
+    `kit-materialize.yml` re-runs the materialize on that PR — the same shape lockfile-sync uses for
+    packages.lock.json.
+
+    This project exists ONLY to reference the package and drive its materialize. It compiles nothing and
+    is deliberately NOT in FS.GG.Net.slnx, so the normal build never touches it. Materialize explicitly:
+
+        dotnet build .config/kit/FS.GG.Kit.receiver.proj -t:FsggKitMaterialize
+
+    The materialized files (skills, scripts/fsgg-coord, .config/dotnet-tools.json) are COMMITTED: the
+    materialize is the write arm that replaces the byte-copy, not a live per-build input, so it does NOT
+    run on every build (FsggKitMaterializeOnBuild=false, per the .github#1280 review). The committed bytes
+    are content-addressed and byte-identical to canonical, so `coordination-coherence` stays green.
+
+    This repo does NOT `receive: build-config` (it hand-authors its own Directory.Build.props /
+    Directory.Packages.props, like audio/templates), so FsggKitMaterializeBuildConfig stays off (its
+    default) — the kit materialize never touches those files.
+  -->
+
+  <PropertyGroup>
+    <!-- A TFM is required by the SDK; nothing is compiled. Matches the repo's band (global.json). -->
+    <TargetFramework>net10.0</TargetFramework>
+    <IsPackable>false</IsPackable>
+    <!-- Tooling-only: no source, no output, no lockfile of its own (the gate locks the solution, not this). -->
+    <EnableDefaultItems>false</EnableDefaultItems>
+    <RestorePackagesWithLockFile>false</RestorePackagesWithLockFile>
+
+    <!-- Materialize into the repo ROOT (two levels up from .config/kit/), on demand — never on build. -->
+    <FsggKitReceiverRoot>$([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)../../'))</FsggKitReceiverRoot>
+    <FsggKitMaterializeOnBuild>false</FsggKitMaterializeOnBuild>
+  </PropertyGroup>
+
+  <ItemGroup>
+    <!-- Version pinned centrally in Directory.Packages.props (CPM; Renovate-managed), like every other pin. -->
+    <PackageReference Include="FS.GG.Kit" />
+  </ItemGroup>
+
+</Project>

.github/workflows/coordination-coherence.yml

@@ -0,0 +1,26 @@
+# coordination-coherence — thin caller for the shared reusable gate (ADR-0019 slice 2; #90).
+#
+# This repo is a `coordination-kit` receiver in FS-GG/.github registry/repos.yml, so it must hold
+# the canonical coordination kit — the cross-repo-coordination + intra-repo-parallel-work skills
+# (.claude/skills + .agents/skills) and the `scripts/fsgg-coord` client. The reusable workflow
+# checks out this repo + FS-GG/.github (the ADR-0019 authority / canonical kit source) and runs
+# `scripts/coordination-sync --check`, failing CI if this repo's copy of the kit has drifted from —
+# or is missing against — canonical. A repo that does NOT receive the kit passes trivially (the
+# gate's `--repo` roster check). Re-seed drift with `scripts/coordination-sync <this-repo-checkout>`
+# from a FS-GG/.github checkout.
+#
+# All mechanics + rationale live in the reusable workflow:
+#   FS-GG/.github .github/workflows/coordination-coherence.yml
+name: coordination-coherence
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read   # pure file comparison against public FS-GG/.github; no packages/write scopes needed
+
+jobs:
+  kit:
+    uses: FS-GG/.github/.github/workflows/coordination-coherence.yml@main

.github/workflows/kit-materialize.yml

@@ -0,0 +1,27 @@
+# kit-materialize — thin caller for the shared reusable workflow (FS-GG/.github, ADR-0062 / #1262).
+#
+# This repo is a `coordination-kit` receiver with `kit-delivery: package`: it references the versioned
+# FS.GG.Kit package (.config/kit/FS.GG.Kit.receiver.proj) instead of taking the kit by byte-copy sync PR.
+# Renovate bumps the FS.GG.Kit pin without running the materialize, so this workflow re-materializes the
+# kit on the bump PR and pushes the refreshed, committed kit back to the branch — keeping the committed
+# kit in step with its pin so coordination-coherence stays green. The package-fabric analogue of
+# lockfile-sync.yml.
+#
+# All mechanics + rationale (App-token push that re-triggers coherence, renovate/*-same-repo gating,
+# self-limiting second pass, provisioning gate shared with lockfile-sync) live in the reusable workflow:
+#   FS-GG/.github .github/workflows/kit-materialize.yml
+name: kit-materialize
+
+on:
+  pull_request:
+    branches: [main]
+
+permissions:
+  contents: read   # the App token inside the reusable workflow performs the write
+
+jobs:
+  materialize:
+    uses: FS-GG/.github/.github/workflows/kit-materialize.yml@main
+    secrets:
+      app-id:          ${{ secrets.FSGG_DISPATCH_APP_ID }}
+      app-private-key: ${{ secrets.FSGG_DISPATCH_APP_PRIVATE_KEY }}

.github/workflows/lockfile-sync.yml

@@ -0,0 +1,53 @@
+# Renovate lockfile-sync — thin caller for the shared reusable workflow (FS-GG/.github#145).
+#
+# Regenerates the committed packages.lock.json on renovate/* PRs so the locked-restore gate
+# (gate.yml — `dotnet restore --locked-mode`, ADR-0006) goes green without a human running
+# `dotnet restore --force-evaluate` by hand. Renovate edits the central <PackageVersion> without
+# running restore, so a referenced-package bump would otherwise fail the gate with NU1004.
+#
+# SCOPE, HONESTLY. The reusable workflow's job is gated
+# `startsWith(github.event.pull_request.head.ref, 'renovate/')`, so this heals RENOVATE-driven drift
+# only. It does NOT regenerate lock files on an ordinary PR. Net commits per-project
+# packages.lock.json today and its gate restores `--locked-mode`; this is the fire brigade that keeps
+# them in step once Renovate starts bumping pins. Renovate is not onboarded on this repo yet (the
+# `renovate/configure` onboarding PR is still open), so like FS.GG.Audio / FS.GG.Templates this is
+# adopted DEFENSIVELY: inert today, correct the moment Renovate goes live.
+#
+# `packages: read` IS NOT OPTIONAL, even though Net consumes no token-gated org-feed package. The
+# reusable workflow declares `permissions: {contents: read, packages: read}`, and a called workflow
+# cannot request a permission the caller did not grant — the run then dies at startup, before the
+# job-level `if` is ever evaluated. FS.GG.Game omitted it and its lockfile-sync startup_failure'd on
+# EVERY run (FS.GG.Game#137). This grants the ceiling so that cannot happen here.
+#
+# ORG-ADMIN PREREQUISITES — both fail loudly, neither is satisfiable from this repo:
+#   1. The fs-gg-cross-repo-dispatch App must include FS.GG.Net with `contents: write`, or the
+#      push 403s.
+#   2. The org secrets FSGG_DISPATCH_APP_ID / _PRIVATE_KEY must be visible to FS.GG.Net, or
+#      `secrets.app-id` resolves empty and the token step fails.
+# Net has never used this App, so assume NEITHER is in place until an org admin confirms (tracked as a
+# follow-up on .github#1291). They only bite once a renovate/* PR exists, which is why this can land
+# ahead of them.
+#
+# All mechanics + rationale (App-token push that re-triggers the gate, renovate/*-same-repo gating,
+# the cold regeneration that avoids committing a hash no fresh clone can restore, self-limiting
+# second pass) live in the reusable workflow:
+#   FS-GG/.github .github/workflows/lockfile-sync.yml
+name: lockfile-sync
+
+on:
+  pull_request:
+    branches: [main]
+
+permissions:
+  contents: read   # the App token inside the reusable workflow performs the git write
+  packages: read   # required ceiling for the reusable workflow's declared packages:read — omitting
+                   # it fails the whole workflow at startup (startup_failure). See above.
+
+jobs:
+  sync:
+    uses: FS-GG/.github/.github/workflows/lockfile-sync.yml@main
+    with:
+      restore-target: FS.GG.Net.slnx
+    secrets:
+      app-id:          ${{ secrets.FSGG_DISPATCH_APP_ID }}
+      app-private-key: ${{ secrets.FSGG_DISPATCH_APP_PRIVATE_KEY }}

Directory.Packages.props

@@ -6,6 +6,11 @@
     <FsGgNetVersion>0.1.0</FsGgNetVersion>
   </PropertyGroup>
   <ItemGroup>
+    <!-- The coordination kit as a versioned package (ADR-0062, .github#1262 / .github#1291).
+         Referenced by .config/kit/FS.GG.Kit.receiver.proj, which materializes the kit onto disk;
+         Renovate bumps this pin and kit-materialize.yml refreshes the committed kit on that PR. -->
+    <PackageVersion Include="FS.GG.Kit" Version="0.1.1" />
+
     <!-- FSharp.Core: the org common pin (Rendering/SDD/Governance/Audio all pin 10.1.301).
          FS.GG.Net.Core depends on FSharp.Core ALONE. -->
     <PackageVersion Include="FSharp.Core" Version="10.1.301" />