Fresh install: Algorithm criterion 12 and the system prompt mandate `Skill("<your-release-skill>")` — a scrub-token skill with no shipped implementation or setup path

[anikinsasha]

Everything below is verified against the public tree at d1d6240 (v7.1.1 payload). Adjacent ground is already filed — #1504 (the consolidated private-references report; deny-list/guard leg), #1488 (DeriveDenyHashes writes into the stripped path), #1541 (ReferenceCheck's missing-reference census), #1558 (self-directed instructions naming payload-absent paths) — and none of it is re-reported here. #1558's body actually names the token this report is about, at the same two system-prompt lines, and deliberately left it out of scope ("cited here only to draw the line"). This is the report on that carved-out class: the mandates themselves.

Two findings.

1. Criterion 12 Requires a Skill No Public Install Can Have

Criterion 12 of the run-completion contract (v8.4.0.md line 47) ends with:

Doc-sync fired when system files changed: Skill("<your-release-skill>", "documentation update — I changed: [files]"). (CHECK at learn)

<your-release-skill> reads as a scrub-time stand-in for the private maintenance skill: RenamePlan.md line 22 tracks it as a rename-at-cut item, InstallEngine.ts line 67 says the skill "only exists in the source repo," and Security/README.md line 96 still names the real path. The same call ships in the system prompt — the privacy self-check at line 162 and "the ONLY sanctioned path" at line 172 — and IntegrityCheck.ts line 375 prints the skill call as the --deep entry point. 15 payload files carry the token.

So a fresh install runs an Algorithm whose completion contract, and a system prompt whose only sanctioned release path, both point at a skill the operator doesn't have, isn't told to create, and — since skills/_LIFEOS/ doubles as the dev-tree refusal marker (InstallEngine.ts lines 153-160) — must not create under the real name. README, INSTALL.md, and GETTING-STARTED.md don't mention any of it. The gap is silent.

2. The Shipped Security Doctrine Ends at ShadowRelease.ts, Which Does Not Ship

The reference class is known — #1541 counted references to private skills as a defect, and the #1504 close says the announced gate exists to catch surviving underscore-skill references. What I want to flag is the doctrine-level case of it: Containment.md line 10 declares "Enforcement: skills/_LIFEOS/Tools/ShadowRelease.ts G1-G14 gates (release-time only)," SystemUserBoundary.md line 115 calls it the "final backstop," and containment-zones.ts line 8 names it the build-time consumer — 20 payload files in total, and no such file ships. A reader auditing the security story from the shipped docs follows the chain to a tool they can't inspect or run. The security docs are where a dangling reference costs trust, not just tidiness.

What This Is Not

The public repo is a generated mirror and the release tooling is private by design (README line 184, InstallEngine.ts line 67) — so this is not a request to publish the skill; it's a request to reconcile the shipped mandates with its absence. I also checked whether anything shipped already fills the role: DeriveDenyHashes.ts covers only the hash half (#1488 territory), and a documentation-sync hook ships and registers at SessionEnd (hooks/hooks.json → DocIntegrity.hook.ts), but nothing in the Algorithm or its docs connects it to criterion 12.

The Ask

1. What should a public install do when criterion 12 fires — name our own doc-sync path? If so, one line in the install docs, or a criterion fallback that names something shipped, closes this. The TestingDoctrine.md specifies test/harness.ts as the probe behind every ISC, but no harness and no tests ship in the release #1550 resolution (a doc status callout) is a shape that would work here too.
2. The ReferenceCheck.ts finds 223 missing references in the shipped payload, has no invoker, and its orphan detection inspects one file #1541 close places ReferenceCheck pre-strip, against the live tree — where skills/_LIFEOS/ exists and every one of these references resolves. Would a post-strip pass against the staged payload be viable? That's the position from which the scrubber's own replacement token (<your-release-skill>) and stripped-tool references (ShadowRelease.ts) become visible; both survive at d1d6240.

Happy to verify whichever fix lands on a fresh tree.