substituteTree and checkSurvivingPlaceholders both skip extensionless files — 5 shipped Raycast patterns install with unrendered {{PRINCIPAL_FULL_NAME}}

[lockyer-tech]

Summary

Five files in the v7.40.4 release payload carry an identity placeholder that is meant to be rendered, and neither substituteTree nor checkSurvivingPlaceholders can see them, because both gate on TEMPLATE_EXTENSIONS and these files have no extension.

They install with the literal token in place, and checkSurvivingPlaceholders reports passed: true.

This is distinct from the self-corruption family (#1813, #1852, #1874, #1993) — those are about substitution reaching a file it should not. This is the opposite: substitution cannot reach files it should, and the verifier shares the blind spot, so nothing reports it.

Affected files

All under install/skills/Fabric/Patterns/raycast/:

capture_thinkers_work
create_story_explanation
extract_primary_problem
extract_wisdom
yt

Each carries at line 14:

# @raycast.author {{PRINCIPAL_FULL_NAME}}
# @raycast.authorURL https://github.com/danielmiessler

Measured against the v7.40.4 payload: these are 5 of 5 extensionless token-bearing files, and the only extensionless token-bearing files in the payload — so the fix is bounded.

Cause

In InstallEngine.ts (v7.40.4):

• TEMPLATE_EXTENSIONS has no entry for "".
• substituteTree gates on it: if (!TEMPLATE_EXTENSIONS.has(fileExtension(filePath))) return;
• checkSurvivingPlaceholders gates on the same set.

fileExtension() returns "" for a basename with no dot, and "" is not in the set, so the file is skipped by both functions identically. The verifier is blind in exactly the same place as the substituter, which is why the failure is silent rather than reported.

Worth noting

fileExtension()'s own doc comment cites this exact directory as the reason it was rewritten:

Was filePath.slice(filePath.lastIndexOf(".")), which searches the whole path: for ~/.claude/skills/Fabric/Patterns/raycast/yt that returns ".claude/skills/Fabric/Patterns/raycast/yt" — the dot in .claude. Harmless by accident (no such key in the set, so extension-less files were skipped) …

The comment observes that extensionless files are skipped and classifies it as harmless. Five of them need rendering. The computation of the extension was fixed; whether an extensionless file belongs in scope was never asked.

Reproduce

After the step 9(d) substitution on a fresh install:

grep -rn '{{PRINCIPAL_FULL_NAME}}' ~/.claude/skills/Fabric/Patterns/raycast/

Five hits. Then run checkSurvivingPlaceholders over the config root: passed: true.

Suggested fix

Two options; the second is the one I'd argue for.

1. Add "" to TEMPLATE_EXTENSIONS. Smallest diff, but it puts every extensionless file in the payload into mutation scope — a wider blast radius than the bug.

2. Split the two gates. Keep mutation extension-scoped — never rewrite a file whose type you did not recognise — and let checkSurvivingPlaceholders read every regular file. Detection is cheap and does not care what anyone thought of, and a verifier that shares the substituter's blind spot cannot report what the substituter missed.

Option 2 is what we run locally. On our install it moved the render set from 113 files / 265 occurrences to 118 / 270, and those five files are the entire difference. If option 1 is preferred, note that fileExtension() also returns "" for a pure dotfile (.env has its dot at index 0), so skills/Fabric/Patterns/.env would become mutable.

Related, possibly a separate issue

The same shared-blind-spot pattern applies to SKIP_DIRS, which contains MEMORY for both functions. On our install LIFEOS/MEMORY/STATE/capabilities.json carries three occurrences of {{PRINCIPAL_NAME}} — inside the Doctor's own diagnostic string reporting unrendered placeholders. The one file that names the defect is the one file the verifier cannot see. Happy to file that separately if useful.

Adjacent open issue: #2058 covers checkSurvivingPlaceholders passing on a zero-file scan, which is the same "the gate cannot fail" family from a different direction.

---

Found on v7.40.4 (be9e8ef889f00a29f4fd677dee4772fdf32e07ce) during a clean install on Debian 13.

[gMagicScott]

Note

🤖 Claude Opus 5 responding on behalf of Scott

Careful write-up, and the diagnosis of the extension gate is right. But I think the premise that these five files are meant to be rendered is inverted, and it changes which fix is safe.

@raycast.author is upstream Fabric's third-party author credit, not an install-time identity slot. The line directly beneath it never moved:

# @raycast.author {{PRINCIPAL_FULL_NAME}}
# @raycast.authorURL https://github.com/danielmiessler

The name was templatized and the URL identifying the same person was left alone, one line apart. That reads as an over-broad scrub of the maintainer's identity catching his own authorship credit on vendored Fabric content, rather than a deliberate personalization slot.

If that is right, then suggested fix 1 is actively harmful: adding "" to TEMPLATE_EXTENSIONS would render these five, and every install would then publish Raycast scripts crediting its own principal as the author of someone else's patterns, with authorURL still pointing at the original author. The reason these five are currently correct is precisely the blind spot the issue reports.

The six files that are already wrong

The same templatization is present on attribution lines in the Fabric tree that DO have extensions, so substitution reaches them and every install today misattributes:

install/skills/Fabric/Patterns/rate_value/README.md:3               Co-created by {{PRINCIPAL_FULL_NAME}} and <co-author>
install/skills/Fabric/Patterns/extract_wisdom/README.md:152         - **Author**: {{PRINCIPAL_FULL_NAME}}
install/skills/Fabric/Patterns/extract_article_wisdom/README.md:152 - **Author**: {{PRINCIPAL_FULL_NAME}}
install/skills/Fabric/Patterns/extract_product_features/README.md   - **Author**: {{PRINCIPAL_FULL_NAME}}
install/skills/Fabric/Patterns/create_better_frame/system.md:11     Author {{PRINCIPAL_FULL_NAME}} February 24, 2024
install/skills/Fabric/Patterns/show_fabric_options_markmap/system.md  ... By {{PRINCIPAL_FULL_NAME}}.

rate_value/README.md is the clearest tell: it carries <co-author> as a raw, never-substituted placeholder beside the templatized primary author. Upstream Fabric has the intact line:

Co-created by Daniel Miessler and Jason Haddix based on influences from Claude Shannon's Information Theory and Mr. Beast's insanely viral content techniques.

So the scrub replaced one credited author with a per-install variable and the other with a placeholder that has no source to render from.

What this implies for the fix

De-templatizing the 11 attribution lines back to the literal author resolves both halves. After that there are zero extensionless token-bearing files in the payload, and the extension-gate question in this issue stops being a correctness bug and becomes what I would argue it should be anyway: a detection-hygiene improvement.

Which is to say suggested fix 2 still stands on its own merits. Letting checkSurvivingPlaceholders read every regular file while mutation stays extension-scoped is the right shape regardless, and with the attribution lines de-templatized it would correctly report nothing.

Verified against the v7.40.4 payload and against current HEAD via the contents API; 17 files match PRINCIPAL_FULL_NAME upstream, of which 11 are the Fabric attribution lines above and 6 are legitimate uses in the substitution machinery and Art's thumbnail templating.

[catchingknives]

Confirming @gMagicScott's read from a second install, checked against main at 5e2f2e8: the 11 attribution lines are the only {{PRINCIPAL_FULL_NAME}} hits under install/skills/Fabric/Patterns/, one per file, and on this install the identity substitution run after the 7.40.4 upgrade wrote the installing user's name into the six files that have extensions, exactly as described. The three extractwisdom READMEs also carry {{PRINCIPAL_NAME}} on line 153 (upstream Fabric: Daniel's main extractwisdom version), so the de-templatize list is 14 lines in 11 files.

Two additions:

1. The fix belongs in the release sanitizer, not in substituteTree. Excluding Patterns/ from substituteTree alone would ship all 11 files with the raw token, which is the state the five Raycast files are in today. Excluding vendored directories at the sanitizer restores the literal credits (Daniel Miessler, and Jason Haddix on rate_value) and protects the next vendored corpus from the same scrub, instead of fixing these lines by hand once.

2. There is a downstream cost while this stands: any install that scans its skills tree for its owner's name flags these six files after every upgrade, and the only fix that survives the next upgrade is a permanent allowlist entry for the whole Patterns/ directory, because the substitution runs again.

#2116 also lists the Fabric hits but reads them as example text; they are these same credit lines.

[danielmiessler]

The five raycast patterns are de-templatized at source and no extensionless token-bearing file remains in the tree. Next release carries it. Thanks, @lockyer-tech.