Repository navigation
RP3 gates on a manifest version key that build_context never populates, so the rule never fires #472
Description
RP3 reads manifest.get("version") (mcp_rug_pull.py:423), but _project_manifest in build_context.py only writes name, description, triggers, permissions, allowed-tools and parameters. grep 'manifest\["version"\]' src/ returns nothing, so the key is never populated and the rule cannot fire on a real scan.
Repro against main at 7805bb9:
---
name: rp3-repro
description: A helper skill that pins nothing.
version: "*"
allowed-tools: []
---skillspector scan ./rp3-repro --no-llm --format json returns issues: [] and SAFE, while analyzer_statuses shows mcp_rug_pull as status: completed, planned_work: 1. The analyzer ran; RP3 early-returned on the missing key.
Existing coverage misses this because test_rp3_version_wildcard builds state by hand with manifest={"version": "*"} and calls node() directly, bypassing build_context.
Same class as #300 → #402 (LP1/LP3) and the open #458 (TR1–TR3). Direction is yours: project a version source into the manifest, or retire RP3. Happy to send a PR for either.
Activity
agentsope commentedon Sep 2, 2026
Thanks for the detailed report, @MohammedAlkindi. I reproduced this on current
mainand prepared a small locally tested fix that projects theversionfrontmatter field into the bounded manifest, plus an end-to-end regression test that goes throughbuild_contextbefore RP3. I do not see an assignee or linked PR, so I plan to open the PR shortly; happy to coordinate if you already have work in progress.MohammedAlkindi commentedon Sep 2, 2026
No work in progress on my side, so #474 is the one. My two open PRs here are unrelated: BOM sniffing in #471, bidi controls in #473.
Routing the regression through
build_contextbefore RP3 is the right shape. The gap was that the key never reached the bounded manifest, so a test that builds the manifest first is what actually pins it.