Someone submitting a team to openrig.dev/rigs now learns before they submit that the registry's check runs rig bundle check on their folder at the submitted ref with the latest published OpenRig, and that any finding fails it. An exported team has no README of its own, so the publishing guide's submit section and the rig-bundles-and-shareable-artifacts skill now say to add one, declare it in rig.yaml docs, and run rig bundle check at the commit being submitted. The skill gains a short section from an exported team to a submission; its mirror and edge digests are regenerated.
4 files, +29 -2 (docs and skill text only). No behaviour, flag or check changes.
Sharing an exported team no longer silently omits its local culture file. `rig export` copies the declared file's bytes next to the YAML for a local daemon, creating declared subfolders, keeping any existing file or symlink with a check-it warning, and skipping a source or destination that would leave either folder. A missing, unsafe or remote source is reported as could-not-copy alongside the existing guidance, and the YAML export still succeeds. Export also names each seat whose agent ref leaves the folder, whether `path:`, absolute, or a relative `local:../` ref like the shipped starter team's, and says how to make it portable. It warns when the installed name remains `starter`, since a bundle's name doesn't rename the rig. The bundle guide covers archive vendoring, README inclusion and checking the culture file over localhost tunnels.
Cost: one declared culture-file copy on local export plus targeted guidance; no agent-tree copying, automatic renaming, new API or live-rig change. Remote and tunnelled exports still need the culture checked from the daemon host, and a successful export is still distinct from a portable, validated bundle. Validation: the escaping-relative-ref case fails before the fix and passes after; 31 export/import checks and the CLI typecheck pass at this head, and the first head's 148 focused checks and daemon build passed. The symlink fixture is skipped on Windows.
Two fixes from a first-user run on a Mac with fresh accounts.
- **Node.js for a standard Mac user:** someone who isn't an administrator, or whose Homebrew belongs to another account, can install Node.js in their own home folder with nvm. They run `touch ~/.zshrc` first, because a new Mac account has none and nvm's installer only adds itself to a profile file that already exists. Then they run nvm's install command, open a new terminal, and run `nvm install 22`. No administrator password is needed, and `npm install -g` then installs into the nvm folder. This is in `docs/reference/getting-started.md` and the README. Nothing is claimed about Node.js's own installer for a standard user.
- **What the registry checks decide:** `docs/reference/publishing-a-rig-bundle.md` now says that a submission with a taken name is still received, that a team sharing a listed team's `rig.yaml` name (such as an unchanged copy) passes with a maintainer notice, and that listing is the maintainer's review decision, not the checks'. Registry policy is unchanged.
Text only. The registry wording was read against `tools/registry-check.mjs` and `tools/ci/bundle-check.mjs` at the registry's main.
A rig bundle can be shared, and anyone with it can read what's inside, so `rig bundle create` no longer packs a harness login file by accident. It refuses `.claude/.credentials.json`, `.codex/auth.json` and `.pi/agent/auth.json`, at the top of an agent folder or carried project or nested anywhere inside one, and the message names the file, says anyone with the bundle could read it, and says how to fix it: remove it and build again, or, only if recipients should have this login (for example, your own internal test bundle) and its owner agrees, recreate with `--include-login-files`.
That opt-in is off by default. It records the exact archive paths of the login files actually included (`included_login_files` in the manifest), and verify, unpack, inspect, the install plan and bootstrap accept only those recorded paths, each with a visible notice. An unrecorded login file, an extra file, a malformed, directory, wildcard or traversal record, or a hash mismatch still fails. The record is the creator's unsigned declaration, not proof of consent, trusted origin or safe credentials. There's no machine setting, force or wildcard.
The check extends the existing shared sensitive-file predicate and integrity verifier, so ordinary `auth.json` files elsewhere and other harness files are unaffected. One fixed-time ordinary v2 bundle and one v1 bundle were checked byte-identical to main's.
Changed results:
1. A bundle that contains one of the three login files, created today without the flag, is now refused, and no archive is written.
2. Existing archives that hold one of those files without a record now fail verify, unpack and install (install returns 400, even with --force or --skip-version-check). Inspection stays a 200 diagnostic with integrity false, and the CLI exits 2.
3. The CLI author check now reports login-file findings, and the CLI and web bundle inspector now show integrity errors.
4. Inspecting a v1 bundle whose manifest can't be parsed or normalized now returns the 200 diagnostic ("Invalid v1 manifest: …"), the same as v2 already did, where it used to fail with 500. Install, verify and unpack are unchanged for those.
Notices and errors name paths, never file contents.
Add a topology naming reference and point the RigSpec, bundle, onboarding and authoring guidance at it, so new teams name pods and seats by purpose, domain and role. Existing rigs and aliases stay supported. Text only.
Brings the README and the reference docs to the 0.6.6 release commit 2620dea8: claims checked against source at that commit, schema-2 and legacy bundle installs described separately, the permission-default exceptions kept in the short summaries, and plain wording for in-flight Slack work.
The publishing guide's "Submit it to openrig.dev/rigs" section now says rig names are unique on the site. If registry/<your-team>.yaml already exists, the registry check says the name is taken; choose a distinct one, for example <taken-name>-<your-name>.
Refreshes `docs/reference/rig-bundle.md`, `bundle-formats.md` and `publishing-a-rig-bundle.md` against main `a350c59b`: adds the flags they were missing (GitHub links, `--non-interruptive`, the install pre-check overrides, `--allow-drift`), states what `--plan` does and doesn't do, notes that `rig up` on a local archive skips the install pre-checks and audit, removes duplicated sections, and adds to the publishing guide what the optional `bundle.yaml` and `configurations.yaml` hold, what `rig bundle check` checks and exits with, the full-commit-ID rule for links, and what links need. Every command and flag was checked against a help capture of that commit. Part of the 0.6.6 developer documentation refresh. Text only.
Section 6 of the publishing guide now tells a submitter to add one file, registry/submissions/<your-team>.yaml, to openrig-world with three fields: repository (the GitHub repository URL), folder (the folder holding rig.yaml, or . for the repository root) and ref (a branch, tag or commit). The registry check accepts that file and says the submission was received. Opening an issue with the same three things still works. A maintainer then writes the full entry in the registry-entry.v1 format defined in the bundle formats reference.
Adds docs/reference/publishing-a-rig-bundle.md: how to lay out a shareable rig bundle folder, check it with rig bundle check, share it as a GitHub folder link at a full commit, inspect and install from that link (rig bundle inspect, rig up with --target and --cwd), choose a configuration with --preset or --seat, and submit it to openrig.dev/rigs through the openrig-world registry, including what review promises. It ends with a block of instructions to give an agent that builds a bundle.
The commands match the shipped CLI; the registry entry format is defined in the bundle formats reference. The guide is installed with the other reference documents under the OpenRig home's reference folder.