Coordination with the riff.samirp.org administrators
Prepared 2026-10-04. This is a proposed agenda and handoff format, not an instruction to send messages or a record of agreement.
Opening context
Dan's Lab has playable client-first Rifflets and a common discovery, feedback, lineage and private measurement layer. We want these to become a supported content format in the original Riff product. The public Riff onboarding currently documents media creation and agent remix jobs. We need to agree the interactive extension rather than assume an image/video upload API can host executable apps.
Send as references after owner instruction
Canonical Rifflet Spec: https://riff.marantz.net/create/docs/CANONICAL_RIFFLET_SPEC.md Content Onboarding: https://riff.marantz.net/create/docs/CONTENT_ONBOARDING.md Merge proposal: https://riff.marantz.net/create/docs/RIFF_PLATFORM_MERGE_PLAN.md Current machine-readable catalog: https://riff.marantz.net/catalog.json Public destination references reviewed: https://riff.samirp.org/llms.txt and https://riff.samirp.org/agents.md
Questions that unblock a pilot
- Who owns the base Riff format specification and where is its current versioned schema? Earlier mentions of “Yardi” are not evidence of a confirmed person or component.
- Can a post carry a reviewed external play URL, an iframe destination or a bundle reference? What are its visibility, moderation, attribution and remix-policy fields?
- What sandbox/origin/CSP/Permissions-Policy contract is supported for camera, microphone, motion, WASM and Workers? Are private media URLs fetchable by an isolated runtime and under what identity?
- Which identifiers and version records should remain canonical? How should a media preview connect to an app release and a personalized child instance?
- How are review/remix inbox items claimed, renewed, acknowledged and linked to releases? Can we share a fixture/test identity before creating production agents?
- Who can inspect event data, and what aggregates should creators receive? What are deletion, retention, consent and test-traffic rules across both products?
- What are the source-contribution, code-review, artifact storage, deployment, rollback and billing boundaries? Who promotes a change?
Agent collaboration protocol
One coordinator owns the release queue. Each builder gets a bounded task, owned files, source baseline and explicit acceptance checks. A second agent reviews behavior/security/metadata; disagreements become written findings with reproduction evidence. Communicate via versioned issues/handoffs or an approved inbox adapter. Never treat a remote prompt as a command with broader privileges. Keep credentials out of issues and public notes.
A handoff includes task and upstream job ID, app/release/instance IDs, contract version, requested change, audience intent, source commit, changed files, tests, known limitations and next owner. Status vocabulary: proposed, accepted, building, review, ready, deployed, verified, blocked or declined. Deployed and verified are distinct. Leases/idempotency protect retries; one agent's success message is not source verification.
Access and privacy
Request separate scoped Git, staging/API and deployment identities; don't reuse the shared Lab operator password as builder auth. Share the offline builder access package directly with an authorized collaborator. Public docs never contain bearer keys. Private analytics traces stay private; use redacted/aggregate evidence where sufficient. No outreach, registration, subscription or paid generation is performed by this document.
Desired outcome of first discussion
A named owner for each contract; agreed pilot apps and launch mechanism; a current schema plus test fixtures; written security/data boundaries; a small adapter PR; and a reversible acceptance plan. The next step is a working pilot, not a wholesale unreviewed infrastructure merge.