/watch

Give it a URL and it fetches the video, samples frames at a rate matched to how fast the content moves, pulls the transcript from captions — or transcribes it directly when there are none — and hands the whole thing over as one readable object.

The first version was useless

It produced summaries. A summary tells you what happened. For someone watching in order to build something, that is worth nothing.

The fix was to ask what the video demands. Not “what is this about” but “what would I have to build to produce this behaviour” — mechanisms, state transitions, failure cases, the parts the presenter skipped. The output changed from a description into an input.

That one line determines the whole design. If you’re producing a description, a transcript alone would do. Producing a spec means you have to see the screen — and the moment you look at the screen, the cost problem starts.

Three problems

	The problem
Frame budget	Almost all the cost is frames, and video length grows without limit
Transcript	Having captions and not having them are entirely different paths
Boundary and failure	What a tool handling other people’s videos sends outside

Where it goes

Sixteen so far, flowing to two places: this site’s analysis archive, and the game project — a spec pulled out of somebody else’s talk gets implemented and tested there.

The loop is the point. Watch, extract, build, break.