Community · E2 · artifact verified
Pick the right viewer for any file
Drop a file or paste a URL and get a floating window with the right tool: Jev decides and composes a viewer from the registry, and when the format is unknown, Haiku invents a spec for a mini-app on the spot.
01 · Role in the system
What Jev does here
The dual-model split does the dividing: Jev decides what a dropped file or fetched URL is and composes the right viewer from a registry of media players, editors, and inspectors; only when nothing matches does the second model (Claude Haiku) invent a spec for a freshly generated mini-app, with a host-built fallback spec when that key is absent. Hosted as a Vite SPA with Vercel serverless APIs (compose, invent-viewer, fetch-resource), with Upstash-backed shared rate limits in production and in-memory fallbacks locally. Keys stay server-side; the live site runs on the author's deployment with the same flow.
02 · Control boundary
Where Jev sits
One decision request maps an input to a registered viewer or an invention path; serverless APIs hold keys, and rate limits guard the hosted deployment.
Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.
03 · Known limits
What this evidence does not prove
- Unknown formats route to a second generative model (Haiku) for spec invention - the record's Jev claim covers the decision and composition layer.
- Invention endpoints run up to 300 seconds serverless; heavy files are bounded by platform limits.
- Viewer coverage is the registry's coverage plus what invention manages that day.
04 · Attribution
Public sources
This is a Community record: the project was published by a third-party community author.