# 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.