@jini-ai/agent-plugins 0.6.16 → 0.6.19

package/ui-ux-design/skills/ui-ux-design/references/ui-loop.md

@@ -0,0 +1,234 @@
+# UI Loop
+
+This is the canonical self-review and iteration reference for page and screen
+design. `ui-ux-design` owns it. Other skills and agents point here instead of
+copying its questions or maintaining separate design checklists.
+
+## Choose The Mode
+
+| Mode | Use it when | Evidence boundary |
+|---|---|---|
+| **Design Intent** | Creating a new surface, writing a design spec, or working without verified browser automation | Answer the eight Core questions from the brief, product constraints, and available artifacts. State assumptions; do not claim rendered verification. |
+| **Rendered Iteration** | An existing or implemented surface can be opened with verified `browser_automation` | Answer every Core question and rendered check from browser evidence at the relevant viewports and states. |
+
+For every page or screen creation, redesign, audit, or visual-polish task, run
+Design Intent mode before finalizing the direction. Add Rendered Iteration mode
+when the browser capability is verified. If an existing surface cannot be rendered,
+finish the Design Intent pass and provide specific manual checks for the unresolved
+rendered items.
+
+This is an internal design gate, not a questionnaire to push onto the user. Ask the
+user only for missing product or brand information that would materially change the
+direction. A weak or uncertain answer means revise, state an assumption, or record a
+tradeoff; do not silently count it as a pass.
+
+When Programmer runs Rendered Iteration, treat Premium quality and trust plus
+Restraint and motion as conformance checks against the approved design/spec, not as
+permission to invent new visual direction. If an honest answer requires a taste
+decision Programmer does not own, stop and request Web Design routing.
+
+## Canonical Review Checklist
+
+In Design Intent mode, answer the bold **Core** question in each category. In
+Rendered Iteration mode, answer the Core question and every nested check with
+`PASS`, `N/A`, or a concrete observation and next correction. Do not apply a fixed
+numeric cap to colors, type styles, or animation; require every added element to
+earn its place in this product and context.
+
+### 1. Purpose and first view
+
+**Core:** Can the target user tell within a few seconds what this page or screen is,
+who it is for, why it matters, and what to do next?
+
+Rendered checks:
+
+- On a marketing page, the hero teaches the offer clearly while creating the
+  intended first impression; it does not become vague in the name of looking premium.
+- The headline, supporting copy, visual, and primary action reinforce the same idea.
+- On an app or tool screen, the first view makes the current context, status, key
+  task, and next decision clear instead of imitating a marketing hero.
+
+### 2. Narrative and copy
+
+**Core:** Does every section or region have one clear job, form a coherent story,
+and use no more copy than the user needs to understand or decide?
+
+Rendered checks:
+
+- The headings alone tell a coherent story when the page is skimmed.
+- Sections explain, prove, differentiate, answer an objection, or convert in an
+  order that matches the user's decision path.
+- Repeated, generic, internal, jargon-heavy, or non-decision-changing copy is removed.
+- Paragraphs, lists, labels, and line lengths are easy to scan, with enough whitespace
+  to separate ideas without making the page feel disconnected.
+
+### 3. Hierarchy, navigation, and action
+
+**Core:** Is there an obvious focal point, reading order, and primary action without
+competing calls to action, confusing navigation, or decorative noise?
+
+Rendered checks:
+
+- One primary action is visually dominant and secondary actions are subordinate.
+- The next step appears where the user is likely to decide, including a clear ending
+  to the page or task.
+- Navigation labels, links, controls, and interaction cues are understandable without
+  guessing, and the critical path has no obvious dead end.
+- Scale, contrast, proximity, and alignment move the eye through the interface in the
+  intended order.
+
+### 4. Visual cohesion
+
+**Core:** Do typography, spacing, color, imagery, icons, depth, and component
+treatments feel like one intentional system rather than a collection of effects?
+
+Rendered checks:
+
+- Typography, spacing, alignment, content widths, and section rhythm are consistent.
+- Palette, type choices, imagery, icon style, radii, borders, shadows, and surfaces
+  feel as though they belong to the same product.
+- Unnecessary colors, type treatments, cards, effects, and competing focal points
+  have been removed.
+
+### 5. Premium quality and trust
+
+**Core:** Does the design feel specific, credible, and polished for this audience
+rather than generic, template-like, or expensive-looking but unclear?
+
+Rendered checks:
+
+- The page has a product- and audience-relevant point of view or focal idea.
+- Images and visual assets are sharp, purposefully cropped, context-relevant, and do
+  useful work such as explaining, proving, guiding, or differentiating.
+- Important claims use truthful, specific proof rather than filler, invented
+  testimonials, generic logos, unsupported numbers, or placeholder content.
+- The final section, completion state, or task ending feels deliberate and leaves a
+  clear next action.
+
+### 6. Restraint and motion
+
+**Core:** Is every additional color, type style, effect, and animation earning its
+place through meaning, feedback, orientation, or brand character?
+
+Rendered checks:
+
+- Each animation improves feedback, orientation, sequence, or brand expression.
+- Simultaneous, repeated, scroll-driven, and decorative motions remain subordinate
+  to the content and action.
+- The experience remains understandable and polished with reduced motion, and motion
+  stays smooth at the tested mobile viewport.
+
+### 7. Responsive behavior and states
+
+**Core:** Does the experience preserve its story, hierarchy, and usability across
+relevant viewports and interaction states?
+
+Design Intent prompts — answer these while designing a web page, before an
+implementation or browser session exists:
+
+- What must the first mobile viewport communicate, and which primary action must
+  remain discoverable there?
+- How do the hero, section order, grids, columns, cards, and supporting proof stack or
+  reflow without changing the story?
+- How do type scale, line length, spacing, density, imagery, and crop behavior change
+  at narrow widths?
+- Which desktop affordances need a touch-safe alternative, and which navigation,
+  form, overlay, table, media, or sticky/fixed patterns are likely mobile risks?
+- What may simplify or move later on mobile without hiding essential meaning,
+  evidence, controls, or recovery paths?
+
+For an implemented website or web app, load `chrome-mobile-test-matrix.md` after
+browser preflight verifies `browser_automation = enabled` when the task can affect
+responsive behavior. Its named viewports and interaction paths are the required
+operational mobile pass; otherwise record `CHROME_NOT_VERIFIED` and manual checks.
+The general checks below do not replace the matrix when it can run.
+
+Rendered checks:
+
+- Mobile preserves the story order with no overflow, clipping, tiny targets, awkward
+  wrapping, or interaction that depends on hover.
+- Wider screens keep intentional content widths and whitespace instead of becoming
+  stretched, sparse, or disconnected.
+- At phone sizes, scroll by touch through every pin, `stacking-cards`, and
+  `horizontal-scroll` section: scroll does not stall or trap, pins are not overlong, a
+  horizontal track does not hijack vertical swipes, and pinned content fits the visible
+  viewport including fixed bars. Only if a section really fights scrolling, fix it or
+  give that section a phone treatment, and record why.
+- Where applicable, default, hover, focus, active, disabled, loading, empty, error,
+  and success states are coherent and visually distinguishable.
+
+### 8. Accessibility, performance, and final craft
+
+**Core:** Is the design readable, accessible, fast-feeling, and complete without
+sacrificing the original user intent or existing behavior?
+
+Rendered checks:
+
+- The critical path works by keyboard with visible focus, and color is not the only
+  carrier of meaning.
+- Contrast, readability, zoom behavior, semantics, and touch-target size are
+  acceptable in the rendered experience.
+- The page feels fast, stable, and responsive, without obvious layout shift,
+  blocking media, janky effects, or visual weight that exceeds its value.
+- No final craft defects remain: misalignment, inconsistent edges, accidental gaps,
+  widows, truncation, placeholders, broken assets, or unfinished copy.
+- Visual changes preserve the original task, application behavior, guards, and
+  product constraints rather than merely making the surface look more polished.
+
+## Rendered Change → Observe Loop
+
+Use this only after `browser-live-analysis` verifies `browser_automation = enabled`.
+
+1. Start the target app and identify the visual target from the spec, reference, or
+   user description.
+2. For a broad redesign, capture a baseline against the Canonical Review Checklist.
+   For a narrow fix, identify the categories the change can affect.
+3. Make one focused presentation-layer change.
+4. Navigate or interact to render it, then capture a screenshot or inspect the DOM,
+   computed styles, accessibility tree, console, and network evidence relevant to
+   the claim.
+5. Compare the observation with the target. Diagnose from the rendered evidence,
+   correct the failed item, and repeat.
+6. Before visual convergence, run every applicable rendered check at the primary
+   desktop and mobile viewports and any task-specific breakpoint or state.
+7. Record remaining items as `N/A`, an explicit user-approved tradeoff, or an
+   out-of-scope seam; never turn an unobserved claim into a pass.
+
+Do not run the complete checklist after every small edit. Use the current failed
+item as the hot-loop target, then run the full pass at convergence.
+
+If Programmer's ambient fast-feedback watcher
+(`harness-engineering/quality/programmer-fast-feedback.md`) is running, do not let its
+output interrupt the hot Change → Observe loop. Consume its stable-failure signal
+during Reconciliation And Handoff.
+
+## Convergence And Pass Budget
+
+- One complete Design Intent or rendered checklist pass is required at convergence.
+- Run a second complete pass only when the first pass caused a material revision,
+  reconciliation changed visible behavior, or the user requested another example
+  or critique round.
+- Do not run more than two complete review passes without explicit user approval.
+  Focused Change → Observe corrections inside a pass do not count as additional
+  complete passes. Track this separately from the Web Design persona's optional
+  concept-critique pass budget.
+- Classify unresolved items as a blocker (clarity, usability, accessibility, or
+  behavior), a quality issue, or optional polish. After two passes, stop cosmetic
+  cycling: diagnose the underlying constraint and ask for direction when a blocker
+  cannot be resolved within scope.
+- Converge when blockers are resolved and every remaining item is an explicit
+  user-approved tradeoff, an out-of-scope seam, or optional polish that does not
+  justify another pass.
+
+## Reconciliation And Handoff
+
+After the rendered result is visually correct:
+
+1. Run the relevant type checker, linter, tests, and accessibility checks.
+2. Re-open the final browser state after reconciliation fixes.
+3. Report the route and viewports observed, the meaningful visual evidence, the
+   reconciliation results, and any unresolved tradeoffs or manual checks.
+
+When only Design Intent mode was possible, label the result as design-reviewed but
+not rendered-verified. Do not claim that a page “looks correct” from static code or
+a design spec alone.

package/ui-ux-design/skills/ui-ux-design/references/visual-storytelling.md

@@ -0,0 +1,54 @@
+# Visual Storytelling
+
+Use this reference for marketing pages, explainers, campaign surfaces, infographics, and interfaces where narrative sequence materially affects comprehension.
+
+This file owns narrative framing and visual-proof selection. `ui-loop.md` owns the
+generic clarity, hierarchy, motion, and final rendered review.
+
+## Core Rule
+
+A narrative surface needs an intentional sequence, not just stacked sections.
+
+## Narrative Frame
+
+Define:
+
+1. setup: what the user understands first
+2. tension/problem: what is difficult, costly, or unclear
+3. resolution: how the product or feature resolves it
+4. proof: why the claim is credible
+5. action: what the user should do next
+
+## Suitable Use Cases
+
+- landing pages
+- product launches
+- case-study pages
+- data storytelling
+- onboarding sequences
+- scroll-based explainers
+
+## Information Design Rules
+
+- keep visual proof close to the claim it supports
+- select charts for comparison clarity, not decoration
+- use progressive disclosure where density is high
+
+## Visual Proof Options
+
+- screenshots
+- before/after comparisons
+- metrics callouts
+- testimonials
+- diagrams
+- annotated flows
+
+## Data Visualization Rules
+
+- choose the simplest chart that answers the question
+- label directly when possible
+- do not rely on color alone
+- use narrative annotations sparingly and intentionally
+
+Select proof that directly supports the narrative claim; the UI Loop determines
+whether it is clear, credible, restrained, and well composed in the final surface.

package/ui-ux-design/skills/vercel-web-design-guidelines/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: vercel-web-design-guidelines
+description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
+metadata:
+  author: vercel
+  version: "1.0.0"
+  argument-hint: <file-or-pattern>
+---
+
+# Web Interface Guidelines
+
+Review files for compliance with Web Interface Guidelines.
+
+## How It Works
+
+1. Fetch the latest guidelines from the source URL below
+2. Read the specified files (or prompt user for files/pattern)
+3. Check against all rules in the fetched guidelines
+4. Output findings in the terse `file:line` format
+
+## Guidelines Source
+
+Fetch fresh guidelines before each review:
+
+```
+https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
+```
+
+Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
+
+## Usage
+
+When a user provides a file or pattern argument:
+1. Fetch guidelines from the source URL above
+2. Read the specified files
+3. Apply all rules from the fetched guidelines
+4. Output findings using the format specified in the guidelines
+
+If no files specified, ask the user which files to review.

package/ui-ux-design/skills/web-compliance/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: web-compliance
+description: Screen website features for privacy, consent, accessibility and policy risks using observed evidence; identify uncertainty for specialist review, without certifying legal compliance.
+---
+
+# Web Compliance
+
+## Purpose
+Provide a practical compliance checklist for website-facing features so review agents can consistently catch legal and policy risks before release.
+
+## Scope
+This skill is a risk-screening layer for product and engineering workflows, not legal advice. It helps teams surface issues early and escalate to legal/privacy/security reviewers when needed.
+
+## Jurisdiction Baseline
+Apply checks based on the strictest applicable region for the release scope.
+
+- EU/EEA: GDPR + ePrivacy (opt-in consent for non-essential cookies/tracking)
+- UK: UK GDPR + PECR (similar consent posture to EU)
+- California: CCPA/CPRA (notice + opt-out model for "sale/share" contexts)
+- Canada: PIPEDA/CASL (privacy + strong marketing consent requirements)
+- US (SMS): TCPA constraints for promotional SMS consent and disclosures
+
+If target regions are unknown, mark as `high` uncertainty and escalate for legal confirmation before launch.
+
+## Use When
+- Feature introduces forms, tracking, cookies, analytics, personalization, ads, or user-generated content
+- Feature changes terms, pricing, claims, consent text, email/SMS capture, account creation, or account deletion flows
+- Feature impacts regional availability or age-restricted experiences
+
+## Core Checklist
+
+### Privacy and Data Handling
+- Personal data collection points are explicit and minimal for the feature goal
+- Sensitive/special-category data is identified and handled with elevated controls where required (for example: health data, racial/ethnic origin, religious beliefs, political opinions, genetic data, biometric data, sexual orientation, trade union membership, precise geolocation where regulated)
+- Privacy notice and just-in-time disclosures are present where data is collected
+- Consent and preference choices are explicit where required (no hidden defaults)
+- Data retention/deletion expectations are reflected in UX copy and flow behavior
+- Data subject request (DSR) mechanisms exist and are usable for access/export/deletion/portability where required
+- DSR identity verification and response-path UX are defined (do not rely on policy copy alone)
+- DSR flow communicates expected response timing/status updates where required (for example: GDPR typically 1 month with permitted extension; CCPA typically 45 days with permitted extension)
+- Frontend collection fields and backend validation contract align (no unexpected extra data accepted)
+- Cross-border data transfer implications are identified for relevant vendors/services and escalated when transfer mechanism evidence is unclear
+- Sensitive fields use safe defaults for storage/autofill behavior appropriate to risk
+
+### Tracking and Consent
+- Non-essential tracking is gated behind consent where required
+- Consent state is honored across page loads and third-party tags
+- "Reject" and "Manage preferences" paths are as visible as "Accept"
+- Consent withdrawal/revocation is as easy and discoverable as consent grant where required
+- Consent actions are auditable (timestamp, policy/version context, and scope) where required
+- No non-essential cookies/tags/pixels fire before valid consent in opt-in regions
+- Consent categories are explicit (for example: necessary, functional, analytics, marketing)
+- Consent UI has no pre-checked boxes and no coercive "cookie wall" patterns where prohibited
+- Region-based consent behavior is enforced server/edge-side, not only via frontend display toggles
+- Push notification permissions are requested with clear purpose/context and respect prior denial/dismissal patterns
+
+### Claims and Marketing Content
+- Product/marketing claims are specific and supportable (avoid unverifiable absolutes)
+- Pricing, trial, and renewal details are clear in the same flow where commitment happens
+- Required disclosures are placed near relevant calls to action
+- Subscription cancellation path is at least as discoverable and easy as sign-up
+- Cancellation is available through the same primary medium as sign-up where required (for example, online sign-up implies online cancellation path)
+- Negative option billing/auto-renew enrollment uses explicit affirmative consent separate from bundled legal text where required
+- Free-trial to paid conversion terms are explicit before commitment
+- Material ToS/pricing/renewal-term changes trigger proactive user notice and re-consent/acknowledgment checks where required
+
+### Email/SMS Capture and Messaging
+- Email capture flow includes clear sender identity and functional unsubscribe path
+- SMS capture includes explicit consent language, program identity, and opt-out instructions where required
+- Messaging consent scope matches actual campaign behavior (no silent purpose expansion)
+
+### Third-Party Scripts and Vendors
+- New third-party scripts/SDKs/pixels/iframes are inventoried in the change review
+- Data-sharing impact is assessed as a potential new vendor/subprocessor risk
+- Vendor data flows are reflected in disclosures/policies where required
+- Non-essential third-party scripts are technically blocked until consent state permits execution
+
+### User Rights and Account Controls
+- Account creation, sign-in, and recovery flows avoid dark patterns (confirm-shaming, roach motel, hidden costs, forced continuity)
+- Account deletion/deactivation flow is discoverable and not materially harder than sign-up
+- Contact and complaint/reporting channels are visible for regulated or trust-sensitive features
+- If automated decisioning materially affects users (for example eligibility, ranking, moderation outcomes), disclosure and human-review escalation path are present where required
+- For personalization/targeting profiles, objection and opt-out controls are discoverable and honored where required
+
+### Age-Restricted Experiences
+- Age gate behavior is neutral and non-deceptive
+- Child-directed and "actual knowledge of minor user" risk cases are flagged for legal review before release
+- Data handling and consent flows for minors are not inferred; require explicit policy/legal alignment
+
+### Accessibility and Fairness
+- Compliance-related controls are usable with keyboard and assistive technologies
+- Critical disclosures are not conveyed by color alone
+- Consent and policy controls are understandable at normal reading level
+- For EU-market digital products, include European Accessibility Act (EAA) applicability check in addition to WCAG baseline validation
+
+### UGC and Platform Governance
+- If user-generated content is in scope, reporting, enforcement notice, and appeal pathways are defined where required
+- Recommender/ranking controls avoid manipulative defaults and are communicated in clear user-facing terms
+
+## Output Contract
+When this skill is applied, output should include:
+- Findings list with `risk_level` (`high`, `medium`, `low`)
+- Exact file/flow references
+- User-facing and regulatory impact
+- Recommended remediation or escalation target (legal/privacy/security/product)
+- Jurisdiction assumptions used for each finding
+- Verification evidence type (`code`, `config`, `network`, `ui-copy`, `flow-path`)
+- Explicit uncertainty notes when legal interpretation is required
+- For `high` and `medium` findings, add audit-style gap framing:
+  - `control_area`
+  - `current_state`
+  - `target_state`
+  - `remediation_steps`
+  - `estimated_effort`
+  - `evidence_needed`
+
+## Audit-Style Evidence Layer
+- Use audit-style gap framing when the feature touches consent logging, DSR flows, retention/deletion behavior, vendor/script controls, cancellation parity, or age-gating.
+- If multiple findings share the same root cause, group them into one remediation cluster and list shared evidence needed.
+- If evidence cannot be verified from code or config, mark it as `missing evidence` rather than assuming compliance.
+- When useful, load `<AI_DEV_SHOP_ROOT>/skills/web-compliance/references/audit-evidence.md` for gap templates and evidence-matrix structure.
+
+## Escalation Routing Heuristics
+- Route to `legal` for jurisdiction interpretation, cross-border transfer mechanism questions, ToS/pricing term changes, marketing claims substantiation, and minor/age-gating edge cases.
+- Route to `privacy` for consent model mismatches, DSR/portability flow gaps, profiling objection controls, retention/deletion mismatches, and disclosure scope misalignment.
+- Route to `security` for backend/edge enforcement failures (for example pre-consent tag firing), identity-verification weaknesses in DSR flows, and third-party data exfiltration risk.
+- Route to `product` for UX dark patterns, cancellation discoverability parity, disclosure placement/copy clarity, and funnel-level remediation sequencing.
+- If a finding spans multiple domains, assign primary owner by root cause and list secondary owners explicitly.
+
+## Guardrails
+- Do not present this skill as legal advice
+- Do not block release on low-confidence assumptions; escalate with explicit uncertainty
+- Prefer concrete evidence (copy text, UI path, config behavior) over generic warnings
+- Do not claim certification or framework readiness from website-surface checks alone

package/ui-ux-design/skills/web-compliance/references/audit-evidence.md

@@ -0,0 +1,59 @@
+# Audit Evidence
+
+Use this reference when `web-compliance` findings need stronger remediation framing or evidence collection structure.
+
+## When to Use
+
+- medium or high risk findings
+- consent and tracking controls
+- DSR/export/delete/account-control flows
+- subscription or cancellation parity
+- vendor/script introductions
+- age-gating and regulated onboarding flows
+
+## Gap Record Template
+
+For each medium/high finding, capture:
+
+- `control_area`: short label for the compliance concern
+- `current_state`: what the product does today
+- `target_state`: what must be true for launch
+- `remediation_steps`: concrete next actions
+- `estimated_effort`: small, medium, large or time estimate
+- `evidence_needed`: what must be shown to verify the fix
+
+Example:
+
+```yaml
+control_area: consent-logging
+current_state: Analytics consent banner is shown, but no evidence of consent timestamp or policy-version capture exists.
+target_state: Consent grant, rejection, and withdrawal are recorded with timestamp, policy version, and scope.
+remediation_steps:
+  - Add server-side consent event persistence
+  - Include policy/version identifier in stored consent records
+  - Add withdrawal path and verify revocation updates persisted state
+estimated_effort: medium
+evidence_needed:
+  - code path for persistence
+  - database schema or event payload
+  - UI flow showing withdrawal path
+  - test or network proof that records are written
+```
+
+## Evidence Matrix
+
+When multiple findings exist, summarize expected evidence with:
+
+| Control Area | Evidence Type | Source | Collection Method | Verification Step |
+|---|---|---|---|---|
+| Consent logging | `code`, `network`, `config` | backend endpoint + client flow | inspect code and capture browser network | verify grant/reject/withdraw all persist |
+| Pre-consent blocking | `network`, `config` | tag manager or edge config | browser/network trace before consent | confirm no non-essential tags fire |
+| Cancellation parity | `ui-copy`, `flow-path` | account settings flow | walkthrough + screenshots | compare sign-up vs cancel discoverability |
+
+## Evidence Rules
+
+- Prefer direct evidence over policy promises.
+- Mark missing proof as `missing evidence`.
+- Group related findings when one remediation fixes several symptoms.
+- Do not infer backend controls from frontend copy alone.
+- Do not mark a control complete unless the operating behavior can be shown.

package/vercel/NOTES.md

@@ -0,0 +1,23 @@
+# Vercel — implementation notes
+
+Host-specific notes moved out of the first host's core comments (2026-10-22, vendor-to-plugins). Core describes these
+behaviours generically; the vendor detail lives here.
+
+- **Account label.** The verified account label is the Vercel `username`.
+- **Project name.** The publish label seeds the Vercel project name (sanitized by `safeVercelProjectName`).
+- **Security headers.** Rendered into a root `vercel.json` from the publish's `responseHeaders`
+  (`targets/vercel.mjs`).
+- **Base path.** Served at the root, so no base path is set.
+- **Deploy poll.** A publish blocks on Vercel's deployment poll (up to about a minute).
+- **Errors.** No code path puts `credential.token` into a `DeployError` message (verified when core's
+  adapter boundary was written); core's message-only boundary holds regardless.
+- **Share links (Vercel Blob).** `object-stores/vercel-blob.mjs` is the plugin's artifact store for site
+  export share links, registered through `tovu-object-stores.json` as provider `vercel` so the share path
+  resolves the saved Vercel connection. It needs the optional `blobToken` credential field (a Blob
+  store's read-write token); without it the share falls back to download-only. Wire format mirrors
+  `@vercel/blob` 2.8.2 `put()`/`del()` (API version 13, `x-vercel-blob-access: public` on put) and has
+  not been exercised against live Vercel yet. The store's binding is its Blob origin, so revoke only
+  deletes through the store the share was put in.
+  No random suffix: the `_share/<16-letter token>/` key is the unguessable part and `delete` only gets the key.
+  Verify is an anonymous HEAD of `<store>.public.blob.vercel-storage.com/<key>?download=1` checking
+  exact size and `application/zip`.

package/vercel/mcp.json

@@ -0,0 +1,4 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
+  "mcpServers": {}
+}