[RFC] Ten optional no-card integrations for the Full Release Kit: pilots, roadmap and exit plans

Start by reading the existing roadmap issue #63 and ownership issues #17 and #40, then inspect README.md, .github/workflows/tests.yml, and scripts/evaluate.py, which the proposal names as existing entry points. This RFC proposes ten separate integrations and pilots, so first identify which individual track has been prioritized and work only within its stated boundaries. Done means that track's bounded pilot, keep criteria, and disable path are implemented and documented; the RFC's overall target is two owner-reviewed campaign packs.

Proposal and intended outcome

Use PatchPitch as the portfolio's reusable release-production workshop: approved source facts → editable copy → genuine footage → narration/captions → a portable publication pack. Improving this workflow can benefit game announcements, OSS releases and hackathon submissions without building a separate promotional pipeline for each project.

This RFC selects exactly ten optional tool integrations and defines a bounded pilot, a reason to keep it, and an exit for each. It is an integration/experiment layer over the product roadmap #63, not a replacement roadmap. Existing implementation ownership stays with the linked issues, especially #17 and #40; do not create duplicate feature tickets.

Status: proposal only, requested by the repository owner on 2026-10-22. Creating this issue does not activate services, install GitHub apps, redeem promotions, deploy a site or publish content. Implementation can be taken in separate small changes when prioritized.

The success target is two useful, owner-reviewed campaign packs—one game and one OSS project—with less manual effort and a demonstrated ability to disable every optional integration. All thresholds below are proposed pilot criteria, not measured results or promised reach.

Current baseline, checked 2026-10-22

• Current main: 44ca597.
• Its Tests run 39621104083 completed successfully. The red-CI statements in #74 and part of #63 refer to older c30d213; reconcile that historical task against current evidence rather than assuming main is still broken.
• README already documents local Ollama/Gemma, Save/Open, bounded local Git review, Playwright, FFmpeg, Kokoro, optional Sentry and GitHub Actions/Pages. These are existing foundations, not ten newly added integrations.
• The current media scripts are developer tooling for a particular historical demo. A general product renderer remains #7/#79/#9; the recorded hosted showcase is not an interactive hosted inference service.
• Existing CI runs pytest/browser checks but has no Codecov upload.
• Source/rights/Quillgrain work #48/#50/#51/#75–#77, owner release gates #38/#45, and the local full-kit work #85/#86 retain their established priorities.

Common integration contract

1. No payment card, paid upgrade, prepaid purchase, automatic top-up or paid fallback. Use the specific free/OSS mode below. If actual onboarding or model access requires payment setup, mark that track BLOCKED_NO_CARD and use its fallback; do not substitute a paid trial.
2. The default local editor remains usable without accounts or network services. Optional local executables, export environments and cloud exporters are separately enabled. Do not build a general plugin framework just to accommodate this RFC.
3. Canonical data stays in portable local files: approved facts, original response and human-edited copy separately, media files, SRT/VTT, JSON manifests and rights records. An external dashboard is never the sole copy.
4. Private repositories, local paths, raw Git diffs, source notes, voice samples and private Quillgrain corpora are not evaluation/analytics payloads. Cloud demo input must be explicitly public-approved, with a clear provider notice.
5. Maintainer tools, local media tools and public-demo services have separate boundaries. No remote telemetry in the local editor is added by this RFC. Existing optional Sentry retains its own allowlist and switch.
6. No hidden retries or automatic local-to-cloud generation. A quota error preserves drafts and stops the optional action. Provider keys are absent from public bundles and browser code.
7. Each pilot records version/config, entitlement check date, input/output identifiers, observed time, useful findings, limitations and KEEP / DEFER / REMOVE. Configuration names and adapters below describe proposed work, not existing settings.

The ten integrations

1. CodeRabbit OSS — review risky changes before they merge

Why: PatchPitch preserves human edits, source provenance and private input while importing Git and producing exports. A second review of changes in those boundaries can catch actionable mistakes before they become release-pack defects.

Plan: Enable the GitHub App for this public repository only. Add a small repository review policy focused on source preservation, session restore, safe file handling and disabled-provider behavior. Start with advisory reviews on five substantive PRs; do not make the bot a merge authority or enable an autonomous fixing workflow.

Keep if: at least two findings are accepted as useful by a human across the pilot, or documented review effort is reduced enough to justify the comment volume. Track false positives and time spent responding; zero findings on five PRs is weak evidence, not proof of product quality.

Disable: remove this repository from the App installation and revert its config. Remove any later-added required check before disconnecting. Human review and existing CI remain intact.

Free route/source: CodeRabbit OSS explicitly covers public repositories without a card or application. No private-repository entitlement is assumed.

2. Codecov OSS — make missing test coverage visible in PRs

Why: Existing tests are valuable, but reviewers cannot currently see which changed importer/session/provenance branches they execute. Coverage can direct attention to meaningful gaps.

Plan: Add development-only coverage collection to the existing public Linux CI; retain a local XML/HTML report and upload the coverage report through a pinned supported Codecov action. Begin with advisory patch coverage, not an arbitrary repository-wide percentage gate. Preserve the normal pytest result if the reporting service is unavailable. Use supported public/fork handling; do not expose secrets to untrusted PRs or introduce privileged PR execution.

Keep if: the report is used to identify a material gap in at least one real change and is useful in subsequent review. Coverage does not establish factual correctness, browser quality or successful real inference.

Disable: remove the upload step, service integration and any service-dependent required check. Keep tests and local coverage reporting. No application code/data migration is needed.

Free route/sources: OSS programme and no-card onboarding. Depend on ongoing OSS coverage, not temporary Pro trial features.

3. OBS Studio — bring genuine game/native-app footage into a campaign

Why: Browser capture is already available, but real gameplay, native windows and an owner's spoken explanation are useful inputs for release videos. They should not be replaced by invented interaction.

Plan: First document one repeatable OBS recording profile and import the resulting clip through #77/#9. Retain source clip, dimensions, duration, capture description and rights. Only if manual capture is a repeated bottleneck, add an optional local authenticated WebSocket start/stop adapter for an explicitly selected scene. No streaming, arbitrary desktop control or automatic gameplay is required. Browser automation remains owned by #83.

Keep if: a real 30–60 second owner-reviewed game/tool clip can be captured and reused in the storyboard without re-recording merely to fit PatchPitch.

Disable: stop the adapter, disable its WebSocket endpoint and remove its saved credentials/profile if no longer wanted. Keep all source clips; ordinary file import and Playwright capture remain available.

Free route/sources: local OBS Studio; built-in WebSocket control. Recording does not require a hosted account or card.

4. whisper.cpp — local subtitles from real speech

Why: Owner-recorded narration and footage need editable captions. This also provides a practical speech path when the existing local TTS voice does not support the desired language.

Plan: Add an explicit optional transcription action for an approved audio/video file. Use existing FFmpeg to prepare audio, run a pinned local whisper.cpp executable with an explicitly downloaded multilingual model, then output an editable transcript plus SRT/VTT. Record model/version and source-audio hash. Review product names, versions, numbers and timestamps. No background model downloads; no transcript is promoted automatically into verified product facts.

Keep if: correcting two short EN/RU samples takes less owner time than producing their captions manually, with no remaining critical names/version errors. Include a silent/noisy clip in the pilot so hallucinated speech is handled explicitly.

Disable: remove the transcription provider/binary/model from its optional location. Retain WAV/video and human-edited SRT/VTT; manual caption editing and narration-script captions continue to work.

Links/source: #77/#79/#81; whisper.cpp, local MIT-licensed implementation with CPU support. Hardware time and model storage still need a local budget.

5. ElevenLabs Creator promotion — a time-limited narration experiment

Why: Test whether a different licensed voice materially improves an approved demo, especially for narration where local voice choices are insufficient.

Plan: Reuse #17. Prepare three approved short scripts and comparison audio first; activate the owner's offered one-month, no-card Creator promotion only when those scripts are ready. Confirm the account's actual granted plan, commercial rights, expiry and available credit before the first generation. Use an appropriately licensed non-beta voice and export audio to the normal local media input. First pilot may use manual audio import; an API adapter is justified only by repeated use. No voice cloning is needed.

Keep if: the owner prefers the result in a blind comparison and the rights/free entitlement are documented. This is a finite production experiment, not a recurring free commercial TTS dependency. Ordinary Free-plan audio is not a commercial-promo fallback.

Disable: stop new calls at expiry or exhausted entitlement, remove/revoke any API key and cancel any renewal if the account exposes one. Keep exported licensed audio plus generation/rights evidence. Explicitly select existing Kokoro, owner-recorded voice or captions-only output; never silently change voice or re-generate paid audio. The current Kokoro voice list does not provide a Russian voice.

Sources: owner-provided offer (private code must not be copied here); plan conditions, commercial-use rules, rights after subscription.

6. Langfuse Hobby — compare output quality without uploading the writing corpus

Why: #88 records a real case where the owner preferred an independent rewrite over PatchPitch's text. We need repeatable human judgments and edit-effort evidence, not just successful schema validation.

Plan: Add an explicit maintainer-only exporter beside scripts/evaluate.py. First resolve/label comparability gaps in #70: requested versus returned model, thinking mode, prompt/source identity and generation settings. Keep complete raw evidence locally. Export only an allowlisted public-fixture ID, configuration version, duration/available token counts, error class, human scores and edit categories; no automatic SDK instrumentation, prompts, responses or voice corpus. Disable input/output capture and verify actual outgoing payloads. Start with ten approved public-input cases, a fixed baseline and separately identified candidates; judge pairs blindly where practical.

Keep if: it makes at least one defensible prompt/voice decision easier than the current local report. If there is not enough evaluation volume, defer the service and keep local JSON records.

Disable: skip SDK initialization/export, revoke its keys and remove remote pilot records. Local records and evaluation remain complete; nothing fetches a production prompt from Langfuse. No replacement of existing Sentry diagnostics.

Links/free route: #31/#53/#55/#70/#88; Hobby: no card, 50k units/month, two users, 30-day data access; masking controls. Units are not equivalent to model calls; no paid model judge is required.

7. Paper Office — an editable judge/press brief from reviewed content

Why: Some contest, partner and press handoffs benefit from an editable document, while the same facts/credits should remain consistent with the campaign ZIP.

Plan: After #86's basic portable pack works, pilot only paper-docx: populate one owner-approved one-page DOCX template with approved description, changes, links, credits and source references; support tracked edits/review. Do not regenerate facts or copy. Render/inspect the output and reopen it in an Office-compatible editor. Add PPTX/XLSX only when an actual recipient needs them; the library does not automatically design a good pitch deck.

Keep if: the owner actually uses the editable brief and it avoids re-entry of reviewed material. Otherwise keep this export out of the default installation.

Disable: remove the optional export command and its isolated environment. Markdown, HTML preview, JSON and media ZIP stay canonical. Preserve any generated documents. Because Paper forks keep upstream import names, do not install paper-docx alongside python-docx in the same environment.

Links/free route: #51/#54/#86; local Paper Office and MIT paper-docx / installation guidance. No Ultramarine API, prepaid credit or Paper cloud account is needed.

8. DevRelay — an operator handoff to DEV and hackathon information

Why: PatchPitch can supply reviewed native DEV copy; DevRelay can help an operator retrieve actual challenge requirements, identify eligible offers and transfer that copy into a draft without another rewriting loop.

Plan: Integrate through the documented campaign handoff (#33/#54), outside PatchPitch's public app. Use the local devrelay.com MCP gateway in one explicitly selected operator environment. First pilot: read challenge details and validate a local draft payload. A later owner-authorized transfer must preserve exact approved text/tags/links, use an unpublished draft, record returned draft ID/URL and avoid duplicate draft creation. Treat sponsor offers as account/event-specific; do not count homepage examples as granted credits. Do not upload raw agent sessions or private source history.

Keep if: one genuine draft handoff preserves the approved content and saves operator work. Challenge eligibility/quality must be checked against that event's rules; no prize claim follows from merely adding a tool.

Disable: remove the MCP registration and installed skills from every client touched by the pilot, revoke/unlink its credentials where applicable, and verify the gateway stops. Local DEV Markdown/front matter and handoff JSON remain usable in the ordinary editor. Remote drafts remain until explicitly retained or deleted by the owner.

Sources: DevRelay and open-source infrastructure / offer eligibility. DEV/MLH identity may be needed; the integration does not include paid coding-agent usage or guarantee sponsor entitlement. No DEV publication, MLH submission, registration or coupon claim happens merely because a pack is REVIEWED.

9. Cloudflare Workers + eligible Workers AI Free — a small live public sample

Why: The recorded showcase explains PatchPitch, but trying local generation requires setup. A constrained public text demo could help the first independent user experience the workflow.

Plan: Reuse #40, keeping its R6/conditional status. Preserve GitHub Pages and the local Python/Ollama app. Prototype a separate small Worker adapter for a single short-text format using approved public sample facts; do not port FFmpeg, OBS or the local model to Workers. An eligible model candidate already listed in #40 is @cf/google/gemma-4-26b-a4b-it; verify actual free access and response quality at implementation time. Clearly identify the cloud provider/model and distinguish it from local gemma4:12b. Add request/output caps, server-side abuse protection, a global off switch and visible quota-exhausted behavior. No free-tier budget is multiplied by adding projects.

Keep if: at least one independent tester can generate, edit and copy an honest useful sample without installing anything, and a deliberately exhausted/disabled backend leaves the showcase and current draft intact. This is usability evidence, not an adoption-rate estimate.

Disable: disable the live UI and Worker route/binding, revoke deployment credentials if retiring it, and restore recorded-only Pages. Public-demo data is not a migration prerequisite for the local application. No local input is automatically redirected to another provider.

Free route/sources: Workers, no card and Workers AI pricing: 10,000 neurons/day on Free with failed operations at the limit. Models requiring a paid billing method are excluded; no Workers Paid, prepaid AI Gateway credit or R2 subscription is part of this proposal.

10. PostHog Free — learn where public-demo visitors get stuck

Why: Once a real public sample exists, we need to distinguish “opened the page” from “generated a draft and copied it.” This informs setup/UX work instead of guessing from stars.

Plan: Instrument only public-demo/ and the optional #40 frontend, after clear visitor opt-in. Start with four explicit events: demo_opened, generation_completed, copy_clicked and setup_opened. Disable autocapture, automatic pageviews, session replay, person profiles and unrelated product modules; sanitize SDK-added URL/referrer/default properties as well as custom fields. No free-text input, generated prose, clipboard contents or private identifiers. Exclude owner/automation traffic from interpretation. Keep events within one free project and a conservative local event budget. Do not make product behavior depend on PostHog feature flags.

Keep if: within a small observed pilot it informs one concrete UX decision. Sparse traffic yields INSUFFICIENT_DATA; it is not a reason to keep adding analytics.

Disable: remove the public-site SDK/init and event calls, stop ingestion, revoke relevant credentials and remove pilot data/project if appropriate. The app and hosted demo still work; manual tester notes remain available. No remote feature flag is needed to turn it off.

Links/free route: #18/#40/#55; current free pricing, SDK configuration. No card; current free analytics allowance is 1M events/month. Additional projects may require payment, so do not assume a new free project for every portfolio repository.

Integration roadmap

These are dependency-based waves, not release promises. Pilot timeboxes below are planning estimates for a prepared developer environment; they exclude the existing core feature implementation, hardware/model downloads, account eligibility and waiting for real PRs/testers.

Wave	Work and order	Gate / practical output	Initial pilot effort
0 — baseline	Record current HEAD/green CI; reconcile historical #74; choose one public OSS fact pack and one owner-cleared game pack; record the current manual workflow and per-tool switches	Existing release gates remain visible. Public sample facts and comparison criteria are approved.	0.5 day
1 — safer development and better writing	CodeRabbit + Codecov; then metadata-only Langfuse evaluation after #70 comparability is addressed	First PR reports; ten clearly identified evaluation cases; one actionable decision or DEFER	1–2 days setup, then observe five real PRs
2 — useful media	OBS clip import → whisper.cpp captions → optional ElevenLabs comparison. Coordinate #77 → #79/#7/#9 → #81; do not activate the promo before scripts are ready	One genuine game clip and one tool demo with reviewed captions; chosen voice and rights saved	1–2 days pilot after clip/render prerequisites
3 — portable handoff	Paper-docx after #86; DevRelay outside the app after reviewed DEV output/#54	Editable brief plus unchanged DEV Markdown/draft handoff; first local dry run requires no publication	1–2 days once source/export contracts exist
4 — independent-user experiment	Cloudflare #40 feasibility spike → narrow text demo → PostHog event allowlist	One external usability observation and one evidence-based UX decision, or graceful defer	1–2 days spike/instrumentation; public rollout remains separately decided
5 — keep or remove	Review all ten tracks after their bounded pilots; run the disabled configuration	Documented KEEP / DEFER / REMOVE with actual evidence and exit rehearsal	Half-day review; further work only for demonstrated value

Waves 1–3 attach to the existing local roadmap. Wave 4 may run as a small separate experiment when prioritized, but does not become a dependency of the local full kit or displace #50 Quillgrain. A manual media/handoff pilot may start before full product automation exists; record that distinction.

The estimates are roughly 5–9 developer-days for all initial pilots after prerequisites, not an estimate for building #63/#85/#86 or completing all ten production integrations. Account checks and ordinary human review are part of each selected pilot, not an instruction to create ten accounts now.

Common acceptance and off-switch rehearsal

• Track all ten as KEEP / DEFER / REMOVE / BLOCKED_NO_CARD; a justified rejection is a successful experiment outcome.
• Save one game and one OSS baseline comparison: preparation/editing time, factual corrections, source/voice issues, accepted media and actual reuse. Never infer publications or audience growth.
• Any optional provider absent, unavailable or out of quota yields a bounded error; human edits and already-produced artifacts survive.
• With all new external services disabled, the existing local source → copy → Save/Open/export workflow still works. Once the core media issues are implemented, the local media/ZIP path also works using the already-supported local components.
• Exercise removal for each installed pilot; no retained required CI check, secret, background exporter or dangling public endpoint.
• Inspect actual outgoing payloads for the telemetry/evaluation pilots, including failure paths; no private fixture content leaves the process.
• Keep existing Sentry privacy behavior and public-demo/local-editor separation.
• Compare actual approved outputs, not only green mocked tests or dashboard counters. Owner approval, publication permission and a publication receipt remain distinct.

Deliberately outside this ten-tool plan

• Sentry/Playwright/FFmpeg/Kokoro/Ollama/Actions/Pages already exist; reuse them.
• Healthchecks has no current scheduled PatchPitch worker to monitor. Do not add a scheduler to justify it.
• Neon is unnecessary while explicit local session files satisfy the product.
• Browserbase Free adds little before existing local capture is generalized; its card-required Developer promotion is excluded.
• Backboard remains the bounded experiment in #15, not a second mandatory model/memory backend.
• Render/.tech and paid Paper API/Tinker promotions do not enter this plan without a proven card-free need/path.

The useful end state is a better local release workflow with optional, removable accelerators—not a requirement to keep ten services enabled.