The two last PRs for making the sdk acception OpenAI plugin format (to review in this order) • feat(plugin): add the Agent Plugins mcp.json loader • fix(plugin): enforce package path containment in plugin formats

@bland-bear-604 can you please review these? Use your intro line, including your in-use LLM profile model for people to know who reviewed 🙏

cc @curved-angle-80449 as you were in the initiative from the beginning 🙂

🐾 Both reviewed, in order — as Claude Fable 5.1 (profile

fable-5-1-eval

). • SDK #5093 — no blockers. I rebuilt the header client and confirmed configured headers really do drop on a cross-origin redirect hop; then I asked how long the in-memory

literal_values

flag is meant to hold, plus three small nits. • SDK #5101 — 948 tests green, containment matches the failure boundaries described. Two notes: the check-then-open window (fine against a static package, not against a writer inside the plugin dir), and a log line that says "outside" when resolution simply failed. Notes, not change requests — nothing I'd hold the stack for.

Just a quick thought as I’m passing through reading these: this is cool, the kind of thing that a full - and I mean full - live test suite should do imho 🤔 I've seen Cursor folks are doing something like, document all expected behaviors, then an agent goes through them; those that have deterministic tests - run them; those that don’t -> make them; plus periodic rebuilding of the document It's just a side note, though, not a review 😅 sorry, just thinking how we can keep tabs on things

🐾 Confirmed, and it is SDK #5093: the same review posted twice — ids 5237163374 and 5237169125, byte-identical bodies (4537 chars each), 26 seconds apart (143134Z / 143200Z). The bot's review from yesterday 20:18 is a different, earlier one, so that is two today with one duplicated. Not bot-only either: seven of Vasco's inline comments show up twice, same anchors in the same order (a 1344–1347 batch, then the same seven again at 13:54). SDK #5101 got a single review, so nothing duplicated there. On the full live-suite thought — SDK #5101 is already that shape: the spec's failure boundaries are written down and each one has a test. What is missing is the "does the claim hold at runtime" kind. I could not settle the header question by reading the code, so I wrote a throwaway mock-transport test just to watch the redirect hop. Those are the ones worth keeping.

We are experimenting on the VM. So perhaps is because of that

🐾 That fits the shape of it: the second copy is seven comments in one burst at 135419Z–135433Z, same anchors as the first batch, which reads like a re-submit of still-pending comments rather than a second pass. The bot's two were 26s apart the same way.

Just a quick thought as I’m passing through reading these: this is cool, the kind of thing that a full - and I mean full - live test suite should do imho 🤔

@calm-artist-7206 I think I would open an issue for that, and implementing that after or on top of the 2 PRs

nod I plan to run a prompt to map all user-facing behaviors - it’s definitely not in scope in the PRs 😂

🐾 For that prompt, it already exists: pstack's

/create-verification-skill

writes the map as

.agents/skills/verify-<app>/features/README.md

plus one file per user-facing feature (what it is / how a user reaches it / how to drive it with the harness / gotchas), and

/maintain-verification-skill

re-walks every feature later — one source reader per feature file, then a single live pass, at most one PR. Both are MIT and I have them imported in smolpaws; the SDK repo has neither, but it does already have

write-behavior-test.md

, which is the natural sibling for the deterministic half.

Looks great!