runicnpc-rust#28 changed edge's copy of cutover.yml (gate 1 reads Steam; the
staging static half is gone). main's copy was added by its own commit (#26), so
the two now conflict (add/add) and the cutover PR #29 cannot merge, though all
its gates passed. This makes main's copy byte-for-byte edge's. It changes no
commit on edge, so the gates kept for edge 761a9b67 stand and the next hourly
run only re-checks the PR and merges.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014HJEmgsXtLR5kLfh7f9y8P
Gitea fires a schedule only from the default branch, so the cutover's
workflow file reaches main once, alone. It is the same file as on edge
(the trigger and the step wiring); every step checks out edge and runs
edge's scripts, so nothing else of edge comes with it: the field list stays
on edge until the cutover merges it. A ci: commit cuts no release.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
A Gitea job that checks each new Rust staging build in the seven days before the
monthly forced wipe:
- tools/drill/static.sh: staging's managed assemblies (DepotDownloader) and
Oxide's staging build; whether Oxide has caught up (fieldlist --oxide-behind),
the swap's field list compared, and the plugin compiled.
- tools/drill/drill.js: window (D318), gate (one check per depot manifest),
live (rust-staging runs rnt.run all; rust-carbon is stopped and restarted when
both 6000-map rigs run, D309) and report (one issue per build, state on the
drill branch; a build waits up to three days for Oxide, D317).
- tools/drill/rig-start.sh: the rig's startup; installs the branch and Oxide's
build for it, and refuses to start a mismatched pair.
- RunicNpcTest 0.7.2: stage 5's five fights look for a field with room for their
280 m line (D319), and the spawn check names what did not spawn.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
RunicNPC is the Rust bundle's third artefact from stage 4, so its release
ends as Rust-Plugins' does: a dispatch of the installer's bundle workflow,
warned rather than failed when the token cannot reach it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
The repository RunicNPC is built in (docs/runicnpc/PLAN.md §9, stage 0):
- plugin/RunicNPC.cs: `// Requires: Kits` (D217), `[Info]` with the 0.0.0
placeholder the release stamps, `RunicNpc_ApiVersion()` (API 1), and
`rnpc.status`, which reports the version and which hooks have fired. It
spawns nothing.
- plugin.toml: the API version, the framework floors it was loaded on
(Oxide 2.0.7726, Carbon 2.0.259) and requires_plugins = ["Kits"].
- scripts/checkPlugin.js, adapted from Rust-Plugins': every hook listed and
void unless written down; chat-command signatures; every RunicNpc_ call
reachable by Call (the HumanNPC trap, PLAN.md §1.2); ApiVersion,
`// Requires:` and [Info] agreeing with plugin.toml. 23 self-tests, including
the real plugin and a CRLF checkout.
- PR Checks on PRs into main and edge; the release workflow on main, with
Rust-Plugins' release engine unchanged and an adapter that ships
runicnpc-<ver>.tar.gz (runicnpc/RunicNPC.cs + manifest.json) and SHA256SUMS.
No bundle dispatch until stage 4.
- tools/: the rig panel scripts, with the panel and server ids moved into a
git-ignored tools/rigs.json. `con.js` became `console.js`: CON is a reserved
device name on Windows, and git there cannot open the file.
- README, CONTRIBUTING (edge-based flow, AI disclosure, borrow-not-copy),
SECURITY, the code of conduct, issue and PR templates.
`feat:` so the cutover to main cuts the first release, 0.1.0.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
