PatchPool

Inspiration

I started with a simple question inspired by mobile-data sharing: could unused Codex resets be donated to someone who needs one more push to finish a task?

That question exposed the most important constraint. Accounts, API keys, credits, subscriptions, and rate-limit entitlements should never become transferable marketplace items.

Instead of moving access between people, PatchPool changes the unit of sharing from an entitlement to a bounded software outcome.

A maintainer describes a blocked open-source task. PatchPool removes likely secrets, narrows the scope, records the safety policy, creates a structured Task Capsule, reviews the candidate artifact, and preserves human authority over the final decision.

The original reset-sharing idea therefore became a safer coordination tool: pool patches, not resets.

What it does

PatchPool provides one visible requester-to-receipt workflow:

1. Accept an allowed https://github.com/{owner}/{repository} URL shape and a bounded task description. The current MVP does not fetch the repository or independently verify its visibility.
2. Redact likely secrets and personal data before any model call.
3. Run deterministic Safety Preflight checks for URL shape, prompt integrity, credential-transfer requests, capability expansion, and execution risk.
4. Compile a structured Task Capsule containing the objective, non-goals, acceptance criteria, allowed and denied paths, test plan, risk, budget, and provenance.
5. HMAC-seal the Task Capsule on the server so that later review can reject tampering.
6. Reserve a browser-local, non-cash demo Task Grant with an idempotent replay proof.
7. Produce a clearly labelled fixture diff without cloning, modifying, or executing the submitted repository.
8. Run a separate review pass. Invalid seals and deterministically high-risk capsules are rejected before model review.
9. Require explicit human action before recording a receipt.

Fixture mode is the default judging path. It completes the workflow with three deterministic checks and can issue only:

DEMO RECEIPT · UNVERIFIED

The interface also states:

UNVERIFIED — no repository tests executed. Deterministic checks only.

A verified Impact Receipt is deliberately harder to obtain. It requires both live reviewer approval and tests.status === passed. Because the current MVP never executes a submitted repository, a verified receipt cannot currently be produced.

How I built it

PatchPool is a Next.js, React, and TypeScript application with server-side route handlers.

Zod schemas constrain inputs and structured outputs. Deterministic controls run before model processing, including:

• GitHub URL-shape validation
• request-size limits
• secret and personal-data redaction
• prompt-injection detection
• credential-transfer denial
• capability-expansion checks
• allowed and denied file scopes
• unsafe-diff rejection
• human approval gates

Task Capsules are sealed using HMAC-SHA256 over canonicalized capsule data. The review API verifies this seal before accepting an artifact and uses constant-time comparison. A production deployment must provide a stable signing secret that is separate from the OpenAI API key.

The OpenAI integration uses the official JavaScript SDK and Responses API with GPT-5.6 structured outputs and store: false.

Task Capsule compilation and independent review are separate model calls. Deterministic code—not the model—retains authority over safety decisions, budgets, permissions, and receipt eligibility.

Codex served as our development partner throughout the project. It helped with:

• researching the product boundary
• turning the original idea into a safer architecture
• requirements and specification development
• Next.js and TypeScript implementation
• threat modelling
• test generation
• debugging
• security review
• claim and demo accuracy auditing
• production of the submission video

The live GPT-5.6 integration is implemented server-side. The currently selected OpenAI Project returns HTTP 429 insufficient_quota, so the reproducible judging path uses the visibly labelled fixture mode. The fixture is never presented as live GPT-5.6 output.

Challenges I ran into

The hardest challenge was not generating a patch. It was designing evidence that could not quietly become a false claim.

I had to preserve several important distinctions:

• A deterministic assertion is not an executed repository test.
• A browser-local reservation is not a financial or durable ledger.
• A SHA-256 digest is not proof that an outcome is correct.
• A fixture fallback is not a live model run.
• Model approval is not human authorization.
• A candidate diff is not a published or merged patch.

I encoded these distinctions directly into the state machine and interface instead of relying only on submission prose.

Another challenge was provenance. If the Task Capsule were passed to review as editable JSON, an attacker could change its risk level, file scope, or constraints before review. I therefore added a server-generated HMAC seal and reject invalid or mismatched capsules.

I also needed fixture mode to fail honestly. It could not silently behave as if repository tests had run. Fixture evidence therefore always returns not_run, even when all deterministic checks pass.

Accomplishments that I'm proud of

• A runnable end-to-end fixture workflow that requires no login or OpenAI API key.
• Visible pre-model redaction of a deliberately fake Bearer credential.
• Deterministic denial of credential, reset, account, and API-key transfer requests.
• HMAC-sealed Task Capsules with review-time provenance enforcement.
• HTTP proof that capsule tampering returns 403.
• Rejection of sealed high-risk capsules before review.
• A browser-local Task Grant that returns the same identifier when replayed.
• Honest receipt semantics: fixture evidence can issue only DEMO RECEIPT · UNVERIFIED.
• A verified-receipt gate that cannot pass without live review and successful repository tests.
• A working server-side GPT-5.6 integration with a safe fixture fallback.
• A security-focused user interface that keeps human authority visible.

Application quality checks completed:

• Vitest: 12 files and 110 tests passed
• TypeScript typecheck passed
• ESLint passed
• Next.js production build passed
• npm audit reported 0 vulnerabilities
• no OpenAI API key markers were found in the client bundle

These are PatchPool's own application tests. No submitted repository tests were executed.

What I learned

Trustworthy AI developer tools need a type system for evidence.

Labels such as fixture, not_run, passed, human-approved, and verified cannot be treated as interchangeable. Each one represents a different level of evidence and authority.

I learned that the most valuable model output is often not an autonomous action. It is a bounded proposal whose provenance, permissions, limitations, and approval requirements are explicit.

I also learned that fallback behavior is a product feature. A reliable demo should fail visibly and recover safely instead of silently replacing a live result with a mock.

Finally, I learned that the responsible pivot can be more interesting than the original idea. Preventing reset and credential transfer led us to a more useful concept: coordinating bounded work while keeping access with its rightful owner.

Security and responsible design

PatchPool was designed with the following boundaries:

• No consumer OpenAI credential field exists.
• No reset, credit, account, cookie, session, subscription, quota, or API-key transfer is implemented or simulated.
• Secret values are replaced before model input and are never returned by the API.
• Request bodies and candidate diffs are schema-validated and size-bounded.
• Submitted task text and model output are treated as untrusted data.
• No user-supplied command is executed.
• No submitted repository is cloned, modified, or published.
• HMAC provenance is checked before review.
• Tampered and high-risk artifacts fail closed.
• Models cannot grant budgets, expand tools, authorize publication, or issue verified receipts.
• Human approval remains required before recording even unverified demo evidence.

What's next for PatchPool

1. Enable OpenAI Project billing and quota, then record the genuine LIVE GPT-5.6 Task Capsule and review path.
2. Add an isolated, network-restricted runner for real repository tests.
3. Produce signed execution attestations that distinguish actual tests from deterministic fixture checks.
4. Replace the browser-local demo reservation with a persistent, append-only, idempotent service ledger.
5. Add identity-backed approvals and abuse-prevention controls.
6. Build a GitHub App that can open a draft pull request only after explicit authorization.
7. Package the safe intake and status workflow as a thin Codex or MCP integration.
8. Explore sponsor-funded, non-transferable task grants while keeping accounts, credentials, and provider entitlements outside the system.

PatchPool's long-term goal is simple: help communities complete bounded open-source work without ever turning accounts, keys, credits, or resets into transferable assets.

Built With

• ai
• codex
• css
• developer
• eslint
• gpt-5.6
• hmac-sha256
• human-in-the-loop
• next.js
• node.js
• open
• react
• responses
• responsible
• shadcn/ui
• source
• tailwind
• tools
• typescript
• vitest
• zod