Skip to content
Back to skills

Repin Goldens

ASecurity

Re-pin failing Enfolded birth digests only for an intentional, human-ratified generator change.

  • 5 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 4, 2026
ai-agentsgonode

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add mark-weeks/hello-nested-worlds-adventure --skill repin-goldens --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Repin Goldens?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Repin Goldens
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/mark-weeks-repin-goldens/badge)](https://www.skillsdirectory.com/skills/mark-weeks-repin-goldens)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: repin-goldens
description: Re-pin failing Enfolded birth digests only for an intentional, human-ratified generator change.
---

# Re-pinning the golden freeze

A failing pin in `tests/test_continuity_freeze.py` means **"you changed
what new worlds are born as"** — not "the test is stale." The store forbids
rewriting born worlds (`birth_world` is idempotent;
`persistence.save_world_nodes` refuses overwrites), so the pins guard
births: fresh installs reproducing the reference seed, and every world born
after your change.

## Before touching any pin

1. **Confirm intent from the request and existing ratification.** Is changing
   birth output the point of this diff, or a side effect? A side effect (an
   accidental extra RNG draw, a reordered bank, a changed breadth range) is
   a bug — fix the code, not the pin.
2. **Apply the specific re-pin approval rule in `CLAUDE.md`'s golden-pin covenant.**
   Identify the owner's approval for this pin change in the current task or PR;
   if missing, ask before changing pins. Present which pins change and why the
   change is safe (pre-launch vs post-launch matters — after first production birth,
   seed/name changes go through the ADR-007 continuity process).

## The procedure

1. Bump `GENERATOR_VERSION` in `multiverse/store.py` for any meaningful
   generator change — it keys the born-world store, so old worlds keep
   their version and new births carry yours.
2. Re-pin at **both depths** — the depth-6 reference world AND the full
   11-level world. Five scales (Room and deeper) exist only below depth 6;
   shallow pins alone are blind to their banks. Update every failing
   surface: node counts, names/world/puzzle digests, breadth profile,
   landmark canaries, and the renewal-epoch puzzle pins (epochs 1 and 2 —
   solved-state rehydration keys include "· Renewal N").
3. **Never re-pin the era-name pins.** The two display banks in
   `multiverse/chronicle.py` are read at render time — editing them
   retroactively renames every era already displayed. They stay frozen
   until eras are materialized (ADR-006 "Revisit when").
4. Record why in the batch's CHANGELOG entry, and name the re-pin as
   intentional in the irreversibility check (see the 2026-08-03 and
   2026-08-04 entries for the expected shape).
5. Run the full `./scripts/check.sh` — the freeze suite must pass green on
   the new pins, with no unexplained changes outside the authorized birth change.

## Completion

Done when the authorized birth change is versioned, both depths and renewal epochs are
covered, the canonical checks pass, and the CHANGELOG explains the ratified change.
Keep existing approval when scope is unchanged; seek a new decision if the affected
pins or continuity consequences change. A failing test alone never authorizes re-pinning.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…