validate the root meta-plugin and reject wildcards in required/optional lists

[charliemeyer2000]

Summary

CI passed on the commit that broke the meta-plugin (c54cabf) because the validator only looked at plugins/* — it never checked the root manifest after the meta-plugin moved to the repo root. Two fixes to scripts/validate-template.mjs:

• Extract the per-plugin checks into checkPlugin(dir, label) and run it on the repo root too (skipping the name-matches-directory check there).
• Add the exact check that would have caught the bug: string entries in requiredPlugins/optionalPlugins containing * fail validation ("globs are only allowed in forbiddenPlugins"), matching the runtime's wildcard rejection.

Verified: passes on current main; fails on the c54cabf manifest with
<root>: optionalPlugins entry "CognitionAI/**" contains a wildcard — globs are only allowed in forbiddenPlugins.

Link to Devin session: https://staging.itsdev.in/sessions/4dedf92ab76a44c78c984fb138682bb0
Requested by: @charliemeyer2000

---

Devin Review

Status	Commit
🟢 Reviewed	9953ac0

[staging-devin-ai-integration]

Original prompt from charlie.meyer

SYSTEM:
=== BEGIN THREAD HISTORY (in #cmeyer-internal) ===
<most_recent_message>
Charlie Meyer (U0AS1R4CM5M) [ts=1785099102.637089]: @Devin help me build enablement materials for plugins. look at notion and C3: Git Plugin marketplace to undersatand what's going on, then help me underastand the state of how plugins work on cloud and local, what morgante is asking for, and then a plan to build this --action-model claude-fable-5-max

Let me search for those threads now.

Those results don't match what you're looking for. Let me search more specifically for mortgante (likely Marco Morgante or similar) talking about enablement materials for plugins with a GitHub repo example.

Got it — that's Morgante Pell. Let me search for his messages about enablement materials and plugins with a GitHub repo example.

Found one — now let me look for the second thread. The first one is from
<#C0B15442C4E>
(eng-plugins-rollout). Let me search for another message from Morgante about enablement/plugins with a usacognition repo example.

I'm clearly finding the same one thread. The second one may involve a
usacognition example repo specifically — let me check if there's another thread where Morgante shared one of those repos.

Let me check the thread on that first message and also look for the second thread — it may have been a reply in a thread rather than a top-level message, or it could be in a different channel.

I found one thread clearly. Now let me look more broadly — the second thread may involve a
usacognition example repo that Morgante shared, possibly in a different channel or as a reply.

I can see a reference in the search results to a second thread — Morgante's "Quick QA on plugins" thread from July 23 against <http://github.com/COG-GTM/plugins-marketplace|github.com/COG-GTM/plugins-marketplace>. Let me find that one.

Found both threads. Here they are:

Thread 1 — Tagging you for enablement materials ownership <https://cognition.enterprise.slack.com/arch... (2957 chars truncated...)

[staging-devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[staging-devin-ai-integration]

Devin Review found 2 potential issues.

Debug

Playground

[staging-devin-ai-integration]

🟡 Validator can wrongly claim there are no plugins, or stay silent when there really are none

The count used to decide whether any plugins exist (names.size < 2 at scripts/validate-template.mjs:129) now also includes the repo-root entry, so the check no longer reflects how many plugins actually live under the plugins folder.
Impact: A repository with exactly one valid plugin is reported as having none whenever the root manifest is missing/invalid, and the message shown is misleading.

How the shared name set conflates the root plugin with the plugins/ entries

names is now module-level (scripts/validate-template.mjs:61) and checkPlugin adds the root manifest's name to it (scripts/validate-template.mjs:77) before the plugins/ loop runs. Two failure modes:

1. Root manifest missing/invalid JSON/missing name → checkPlugin returns early without adding a name, so a repo with one legitimate plugin yields names.size === 1 and emits the spurious no plugins found under plugins/ error.
2. Conversely, if two plugins under plugins/ share the same name, the set dedupes them, again skewing the count (duplicate is separately reported, but the count is not a plugin count).

A robust fix is to count plugins encountered in the plugins/ loop with a dedicated counter rather than reusing the shared name set.

Prompt for agents

In scripts/validate-template.mjs, the 'no plugins found under plugins/' check was changed from names.size === 0 to names.size < 2 because the shared `names` set now also receives the root meta-plugin's name from checkPlugin(). This makes the count depend on whether the root manifest parsed successfully and on name uniqueness, so a repo with one valid plugin plus a broken root manifest reports a misleading 'no plugins found' error. Track the number of plugin directories actually validated under plugins/ with a separate counter (incremented in the loop) and use that for the emptiness check, keeping `names` solely for duplicate detection.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

Debug

Playground

[staging-devin-ai-integration]

🔍 Wildcard check only inspects string entries, not object refs

The new guard only rejects wildcards for string entries in requiredPlugins/optionalPlugins. An object ref such as { "source": "git-subdir", "path": "plugins/*" } (or a wildcard in url) would slip through, and the sibling-resolution check below would just report a non-resolving path (or nothing, if the URL isn't this repo). If the runtime rejects globs anywhere in required/optional refs, consider also checking ref.path/ref.url for *.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

Debug

Playground