update io.pilot.bowmark v1.0.1: attributable app-store traffic, and a demo that fits a small context

[Metroxe]

One file, submissions/io.pilot.bowmark/submission.json, version 1.0.0 → 1.0.1.

Thanks for the e2e writeup on #97: the broker detail in it is what made this PR possible, and what made me throw away my first attempt.

1. Attribution, via the method path

We cannot currently tell Pilot-driven traffic apart from anyone else's. Our MCP endpoint carries the installing directory in the URL (/mcp/registry, /mcp/smithery), but the two REST routes the adapter fronts are the plain published ones, so an app-store arrival is indistinguishable from someone who pasted the endpoint by hand.

"path": "/v1/library"   ->  "/v1/pilot-app/library"
"path": "/v1/run"       ->  "/v1/pilot-app/run"

pilot-app is a registered destination on our side, live in production now. An unrecognised segment falls through to normal handling rather than 404ing, so this cannot break in the direction that matters.

My first attempt was a second backend.headers[] entry, and it would have silently done nothing. Submission.BrokerEntry takes the first non-empty header as AuthHeader and breaks, so a second entry never reaches broker.AppEntry; and broker.go builds a fresh upstream request carrying only Content-Type and the injected key, exactly as its comment says. I ran your broker locally against an echo upstream to be sure:

UPSTREAM RECEIVED GET /v1/pilot-app/library?query=flights
   header: Authorization: Bearer <injected>
   header: Content-Type: application/json

The path survives, no custom header does. So the header is gone from this PR and the path carries it. Nothing changes on your side: allow is derived from the same http.path values, so registration and forwarding stay consistent by construction.

If arbitrary header pass-through is ever interesting to you as a feature, we would use it, but the path works today and needs nothing from you.

2. The demo now scores 100.0, from 90.0

demo-score put us at 90.0 on #97, and the whole 10 points were brevity: the rendered SKILL was 5145 bytes against the 3000 target. Since that skill is injected into a small-context agent's window, that is a real cost and not just a number.

	#97	this PR
Score	90.0	100.0
Rendered SKILL	5145 bytes	2982
First-call proxy	1.00	1.00
Examples	5	3

The counter-intuitive part, for anyone reading this later: cutting two examples cost nothing. The rubric bands examples at 2 to 6, so 3 and 5 score identically, and the two we dropped were a second fan-out that duplicated the first and a Promise.all whose lesson the remaining drill-down example already teaches. What is left covers the three genuinely different shapes: a capability that fans out across sites, reading an arbitrary page, and calling one named provider with two dependent calls in a single script.

3. One line that would have failed your validator

next_steps.edges[2].then[0].why had grown to 242 chars against your 160 limit, from a copy change we made after #97 merged. TestAllSubmissionNextStepsValid caught it. Fixed here.

Validated

go test ./internal/publish/ ./internal/demo/ ./internal/demoeval/ ./internal/nextsteps/ all pass off current main, and demo-score reports 100.0 / ok.

Changelog

• Route the app's two methods through /v1/pilot-app/*, so calls arriving from the Pilot Protocol app store are attributable. No change to method names, parameters, or behaviour.
• Rewrite the product demo to fit a small context window: 5145 bytes down to 2982, three worked examples covering three distinct shapes rather than five with overlap, and tighter gotchas.
• Document incomplete.failures[].fixable on a partial result, so an agent can tell its own rejected argument from a site that did not answer, and retry only what is worth retrying.