Files
captoys/toybox-stories.md
dckc 1aeb3a21db capsite: toybox user stories and goals (T1-T3)
toybox-stories.md: the weekly roundup (#23), album-to-album sync
(endojs/playground#16), and drag-to-archive.org (#118), with the needs
they share. The checklist gains the toybox tree: a changed signal (T1),
Blockly composition by petname (T2), and confined code in Dynamic
Workers (T3).

Generated-by: Claude Opus 5.5
2026-10-07 20:33:08 -05:00

75 lines
3.2 KiB
Markdown

# toybox user stories
What the pieces are for. A goal in [the capsite checklist](capsite-checklist.md)
earns its place by serving one of these; architecture with no story
waits.
## S1. Weekly roundup
> Monday morning, I open madmode and find last week's bookmarks waiting
> as a draft roundup. I drop a few, add a line of commentary to a
> couple, and publish: 10 minutes, not an hour of copy-paste.
[Weekly PESOS a la Tim Bray, madmode-blog#23](https://github.com/dckc/madmode-blog/issues/23).
Later sources join the same weekly shape: Zotero additions
([bib sync, madmode-blog#195](https://github.com/dckc/madmode-blog/issues/195);
[the zotero goal tree](zotero-checklist.md)) and social.coop posts
([the social.coop goal tree](social-coop-checklist.md)).
- source: the diigo cache, read-only (public items)
- sink: a madmode draft post
- trigger: weekly, a human in the loop
- glue: editorial — the human picks and comments
## S2. Album to album, unattended
> Every time I add a photo to Google Photos album A, it shows up in
> Amazon Photos folder A' (so it's on the TV).
[Copy on insert, IFTTT-style, endojs/playground#16](https://github.com/endojs/playground/issues/16);
context in [photo album on TV, madmode-blog#118](https://github.com/dckc/madmode-blog/issues/118).
- source: Google Photos, read-only, **one album**, with a stream of
photos added to it
- sink: Amazon Photos, write to **one folder**, plus a read-only
view of it to avoid duplicates
- trigger: each insert, nobody watching
- glue: a one-line rule
## S3. Drag photos to archive.org
> I browse my Google Photos and drag the ones worth keeping onto an
> archive.org target, which publishes them.
[The drag-and-drop comment on madmode-blog#118](https://github.com/dckc/madmode-blog/issues/118);
background in [archive.org and IPFS for the commons, madmode-blog#108](https://github.com/dckc/madmode-blog/issues/108).
The plugins should be "boring enough for an LLM to do most of the
work", given [ocap-discipline clues for LLMs, awesome-ocap#55](https://github.com/dckc/awesome-ocap/issues/55).
- source: Google Photos, read-only
- sink: archive.org, post
- trigger: a human gesture (drag-and-drop)
- glue: a UI that holds both capabilities
## What the stories share
| need | S1 | S2 | S3 | goal |
|---|---|---|---|---|
| session-cookie read where the official API is closed | diigo | Google Photos | Google Photos | webapp (done for diigo) |
| a cache of what's been read | ✓ | ✓ | ✓ | 1c (done for diigo) |
| fresh data | ✓ | ✓ | | 1f |
| **narrowed capabilities** (one album, one folder, public only) | public only | ✓ | ✓ | *no goal yet* |
| a changed signal / stream of additions | | ✓ | | T1 |
| generated code, confined | | rule | plugins | T3 |
| visual composition | | | | T2 (no story yet: parked) |
Notes:
- Google's Photos Library API stopped serving a user's own library in
2025 (only media the app itself uploaded), as far as we know; that's
the diigo situation again, and why #118 links a
[browser-console approach](https://github.com/Ninefrm/console-automation-google-photos/).
Check before building on it.
- S1 is the first to ship; S2 is the first unattended one, so it's
where T1 and narrowed capabilities stop being optional.