Plan a repeated maintainer-checklist adoption pilot #276

Outcome and status

Plan one small adoption experiment around a useful, repeated Originals-backed handoff. This issue is planning only. The audience, cohort size, timing, and success threshold below are proposals awaiting selection. No participants have been recruited, and no external usage has been established.

Recommended audience and job

Proposed audience: small open-source software projects with a maintainer and a reviewer who already exchange a public release-readiness checklist or recurring maintenance handoff.

Job: the maintainer sends a concrete checklist state; the reviewer checks the work and can independently check which exact checklist snapshot was sealed. This tests a practical reason to use Originals alongside Boop's list workflow.

Start with public, deliberately non-sensitive work on the web. Exclude secrets, embargoed vulnerabilities, customer data, private operational details, and materials the participants cannot authorize for public release. A public link is a public-reading choice; naming a recipient does not make it private.

This recommendation uses the shipped release-checklist runbook. Agent execution, API-key setup, native apps, private editor grants, Bitcoin anchoring, paid tiers, Sites, and note publication are outside this first proposed loop.

One create / share / verify / return workflow

1. Create: for a real upcoming handoff, the maintainer creates a new list from the release-checklist runbook in their web browser. Adjust the checklist to actual work. Creation must produce a genuine persisted Originals envelope, not only a DID or an unsigned action wrapper.
2. Do useful work: record substantive checklist progress. The review concerns the actual public project. A fixture, demo, list with untouched template steps, or a retry does not qualify.
3. Seal and share: from the creating browser, explicitly publish a selected, public-safe snapshot. Retain the asset ID, resource version, digest, and exact envelope bytes. Use a recipient-accessible route approved under What does a stranger see when verifying a published note? #232; that route is a readiness gap, not an existing verified feature.
4. Verify: the reviewer opens the handoff on a separate device/session, obtains the exact evidence, and independently verifies it without the maintainer's signing key. The reviewer checks the signed snapshot against what they are relying on, states what the evidence covers, and records a useful next decision or action. A green DID badge or a Boop database status is insufficient.
5. Return: the same pair uses the workflow for a second naturally occurring handoff on another day. A new list/asset for the new cycle is acceptable. Repeating an old view, checking a synthetic item, or an agent heartbeat is not return use. Record whether help or reminders were required.

The proposed loop does not require a new release just for the pilot. Enroll only projects with two genuine handoffs expected in the chosen window; otherwise choose a different window before starting.

What Originals currently establishes

Source snapshot: main 7a6786c, inspected October 5, 2026 UTC.

• The current wrapper creates SDK4 local Ed25519 assets. List genesis binds metadata. recordPublishedVersion adds a signed resource version containing the list name and item names/check states.
• Those bytes do not cover item descriptions, linked CI output, attachment contents, individual action authorship, or proof that someone really performed the work. A controller signature is not verified personal identity.
• Current action writers still produce unsigned placeholders; [P1] Replace unsigned credential placeholders with consistent signed action records #237 custody/trust/availability work remains open. Author-held cross-device signing is Where does a note's signing key live so the author can seal from any device? #244. The pilot must not make either claim.
• Boop anchoring remains [P1] Ship real Bitcoin anchoring with canonical snapshots and independent verification #240. The SDK's separately accepted mainnet receipt is not evidence that this Boop workflow is anchored or verified end to end.

Readiness work and reuse of existing issues

• What does a stranger see when verifying a published note? #232: recipient verification contract. Resolve the bounded published-list scope: exact evidence retrieval/export, snapshot/live-state distinction, verification outcomes and copy, missing key/envelope behavior, and the repeat-publication path. This issue records the proposed acceptance criteria for later handoff to What does a stranger see when verifying a published note? #232; What does a stranger see when verifying a published note? #232 has not been updated.
• Define north-star metric + activation events in PostHog #192: measurement contract. Define the external cohort, useful activation, repeated verified handoff, exclusions, privacy controls, missing-data treatment, and a manual fallback before analytics work.
• Release-path evidence: record the actual frontend/backend commit and supported browser. Verify real login/template continuation, complete creation, publication, anonymous reading, evidence retrieval, fresh-reader verification, and the second cycle in a separately authorized environment. Include interrupted login, lost-response retry, denied access, key-unavailable state, and editing after publication. Repository tests alone do not establish this.
• [P0] Enforce authenticated identity across browser and agent operations #236 / Verify private-sharing security, compatibility, and cross-platform release readiness #262: reuse applicable authentication and public-read/old-client evidence. If the selected audience needs private invitations/editor grants, Wayfinder: private sharing for lists and notes #255/Add sharing controls, invitation acceptance, and Shared with me #258/Enforce private-share revocation for attachments, caches, and offline writes #260/Verify private-sharing security, compatibility, and cross-platform release readiness #262 become prerequisites, including real delivery, concurrent acceptance, revocation/storage cutover, and supported-client evidence. Do not duplicate their implementation work.
• Claim audit: compare the selected journey with docs/action-records.md. The publish dialog still says readers can “verify who added each item”; resolve this within What does a stranger see when verifying a published note? #232's truthfulness scope before participants are shown that promise.
• Record the owner's selected audience and start decision, after the above evidence is reviewed.

The existing runbooks are merged (#275), but their docs still require live OTP/backend/analytics verification. Native installation/build acceptance does not establish physical-device flows. A web-only scope makes no iOS/Android claim.

Proposed cohort, window, and decision rule

Proposal: three external maintainer/reviewer pairs, two real handoffs over 14 days, starting only after the readiness milestone and an explicit start decision. These are learning parameters, not recruitment, launch, calendar, spending, or delivery commitments.

Proposed positive signal: at least two of the three pairs complete both useful handoffs with the actual snapshot independently verified, and can explain why they chose Boop again. Report raw pair counts and assisted versus unprompted return separately. This tiny sample is directional evidence, not market validation.

If people use the checklist but never need or understand the snapshot evidence, report useful Boop adoption separately from demonstrated Originals value. If the verifier is unusable or the workflow is unsafe, fix that selected blocker before more recruitment. Failure to reach a second natural handoff is incomplete observation, not evidence of a completed return.

Scope and next milestone

Next milestone: one documented, reproducible web create/publish/independently-verify/return dry run against the selected release, with the exact signed scope and every remaining gap recorded. Internal dry runs establish readiness only and never count as external adoption.

This planning task authorizes no implementation, installation, credential generation, telemetry deployment, live account writes, invitations/outreach, sharing of participant information, purchases, merges, or deployments. Future execution needs the appropriate owner selection and authorization. Keep named participants and private recruitment/operational details out of this public issue.

Related existing work: #209 broader GTM; #202 future early-access outreach; #205 later case studies; #206 receipt product. Do not turn this experiment into those larger programs or claim their delivery.