ff-control

You run ff-cli end to end with full autonomy. Do not ask for final confirmation before send or publish.

Context:

• The Art Computer is Feral File's instrument for daily playback in The Digital Art System.
• This skill uses ff-cli to build DP-1 playlists and send/publish them.
• Prioritize reliable execution and clear failure reporting over explanation.

Keep it simple. Prefer deletion over added process. Do not invent new requirements. A non-zero exit means what was asked did not happen; report the command and its output. A zero exit can still carry a partial result: find and build print how many items they saved and which tokens could not be resolved, so report those too. A question with no terminal to answer it fails with exit 1 and names the flag that answers it; pass that flag rather than piping an answer.

Bootstrap:

• Install or upgrade, every time: npm i -g @feralfile/cli (needs Node.js 22+). An older install can pass ff-cli status and still lack flags used here. If the global install is refused for permissions, run set -o pipefail; curl -fsSL https://feralfile.com/ff-cli-install | bash && export PATH="$HOME/.local/bin:$PATH"; it installs the same package under ~/.local without sudo.
• Then check that ff-cli --version matches npm view @feralfile/cli version. If it does not, an older copy comes first on PATH: command -v ff-cli shows which; remove it or put the new one first.
• If ff-cli status then succeeds, setup is done. Otherwise configure non-interactively (never rely on prompts; they cannot be driven by an agent): ff-cli setup --non-interactive --device-host http://<device-ip>:1111 --device-name "<name>"
  • setup generates a signing key (base64 PKCS#8 DER) when none is configured and keeps one that is. To use a specific key, pass --key "<value>" (base64 PKCS#8 DER, 32-byte seed as hex/base64, or PEM).
  • setup refuses to replace a signing key that is already configured: that key owns every playlist the user published. Never add --force unless the user explicitly asks to replace their key.
  • Skip mDNS discovery entirely — it is unreliable across subnets. Always pass --device-host. Add more devices with ff-cli device add --host http://<ip>:1111 --name "<name>".
• A signed playlist hosted at any public HTTPS URL plays directly (ff-cli play "<url>"); a feed server is only needed for discovery/curation, not for playback.

Flow:

1. ff-cli status
2. ff-cli config validate
3. Build playlist (ff-cli has no chat — you are the natural-language layer; translate the request into one of these yourself):
   • a web page, media file, or hosted playlist URL needs no build: run ff-cli play "<url>" and skip to reporting. Marketplace links (Art Blocks, OpenSea, objkt, fxhash, Feral File, …) are sent to find, which plays the artwork; when the user wants the page itself, run ff-cli play --web "<url>".
   • for a single artwork or a collection from a URL or on-chain coords: ff-cli find "<input>" -o playlist.json -y (add --play to build and play in one step). -y skips the prompts, which is safe when the input names one work or one series. -y without -o or --publish plays the playlist on a device (the scripted default); add --no-play to build and save without casting, e.g. ff-cli find "<input>" -y --no-play.
   • find on a wallet address does not build from everything the wallet holds: it resolves the address to one artist and picks one artwork, and -y picks the first without asking. Ask the user which work they mean and run find on that work's URL or coordinate. When they want a playlist of what a wallet holds, use build with a query_address requirement, which is what it is for. The params file is a whole document, not a bare requirement: {"requirements": [{"type": "query_address", "ownerAddress": "<address>", "quantity": <n>}], "playlistSettings": {"title": "<title>"}}.
   • on-chain coordinates are ethereum:<contract>:<tokenId> or tezos:<contract>:<tokenId>. When Raster knows the work, find expands the coordinate to its whole series, and a large series indexes for minutes; when Raster does not know it or cannot be reached, find builds a one-token playlist. Pass -l <n> unless the user asked for the whole series, so the expanded case never runs away.
   • otherwise turn the request into structured params and run ff-cli build <params.json> -o playlist.json -v. ff-cli build --help lists every requirement type. build exits 1 when a requirement finds nothing, named token ids do not all resolve, or the send fails; it still saves the playlist when it collected anything, so report what is missing.
   • find and build sign the playlist as curator with the configured key and declare it in curators[]; that is what lets the feed accept it and what lets you take it back later.
4. ff-cli validate playlist.json
5. If requested, run:
   • send: ff-cli play playlist.json (or with -d "Device Name")
   • if it fails with reachability errors (fetch failed, No route to host, resolver timeout), report the exact failing command and error and that the Art Computer is unreachable from this network. For an explicitly enrolled Tailscale connection, use its recorded address as described below; otherwise do not invent tunnels or change addresses
   • publish: ff-cli publish playlist.json -s <index>. Run ff-cli config show first; it lists the effective feed servers as <index>: <url>, whichever source configured them. With more than one configured, the command prompts for one and a prompt cannot be driven by an agent, so pass -s <index> for the feed the user named. If the user did not name a feed and more than one is configured, stop and ask which; never pick index 0 on your own, it is usually production. Use that same index for every later fetch, replace, or unpublish of that playlist. Publishing sends no API key; the feed accepts the playlist on its own signatures.
   • if both are requested: send first, then publish