DevRelay

The agentic engineer that builds tickets for you.

Comment

DevRelay Customer signals. Engineering action.

Category: Work & Productivity Built with: TypeScript, React, Vinext, Vite, Cloudflare Workers, Cloudflare D1, Codex, and GPT-5.6

Before submitting: Replace the links below with the final public URLs.

Live demo: Open DevRelay

Code repository: View the repository

Demo video: Watch the demo

Inspiration Customer-facing teams often have the information needed to explain an urgent software problem: business impact, reproduction steps, screenshots, and logs. Engineering teams need a different view of that same issue: likely code ownership, relevant files and tests, implementation risks, and a concrete definition of done.

Translating between those perspectives is usually manual, slow, and lossy. Important evidence can disappear inside long chat threads, while rushed tickets can force engineers to repeat the investigation.

DevRelay was created to make that handoff faster and more trustworthy. It converts a customer escalation into a structured engineering ticket while preserving evidence, labeling uncertainty, protecting sensitive information, and requiring human approval before handoff.

What it does DevRelay is a B2B support-engineering workspace that combines a sanitized escalation report with a read-only repository snapshot. It identifies relevant implementation paths and generates a reviewable engineering ticket grounded in cited repository evidence.

The workflow is straightforward:

Support records the customer-visible problem, impact, expected behavior, observed behavior, reproduction steps, and available logs.

DevRelay removes common sensitive values before analysis.

A deterministic analysis provider compares the sanitized report with an indexed, read-only repository snapshot.

The product surfaces relevant files, symbols, tests, and documentation as evidence.

DevRelay produces a structured ticket containing findings, a root-cause hypothesis, an implementation plan, acceptance criteria, risks, and a test plan.

A human reviews and edits the result before explicitly approving the engineering handoff.

The current demo requires no AI credentials or live repository connection. It includes realistic escalation data, curated repository snapshots, persistent user authentication, and a complete local workflow.

Key features Escalation workspace Dashboard showing open escalations, severity distribution, workflow status, and recent activity

Validated intake for customer impact, expected and observed behavior, reproduction steps, logs, attachments, and repository selection

Multi-stage analysis experience with explicit privacy and repository-access boundaries

Detailed escalation view connecting the original report, analysis, evidence, and generated ticket

Evidence-backed engineering tickets Each generated ticket includes:

Issue summary and customer impact

Expected and observed behavior

Findings with cited repository evidence

Root-cause hypothesis with a confidence score and explicit uncertainty

Proposed implementation plan

Acceptance criteria and test plan

Risks, edge cases, and definition of done

Users can compare evidence and ticket content in a two-column review interface, edit the generated sections, and export the result as Markdown or JSON. Clipboard export supports Jira, Linear, and GitHub Issues workflows. Approval and “sent to engineering” are separate, explicit actions.

Authentication and product quality Persistent Cloudflare D1 user accounts

PBKDF2-SHA-256 password hashing with a unique salt per account

Revocable server-side sessions backed by hashed tokens

HttpOnly, SameSite=Lax, seven-day session cookies

Protected application routes and explicit sign-out

Responsive desktop and mobile layouts

Semantic controls, visible keyboard focus, and reduced-motion support

Purpose-built empty, loading, error, and success states

Typed domain models and explicit workflow transitions

Automated tests for authentication, redaction, validation, ticket generation, exports, and workflow rules

How we built it DevRelay is a TypeScript application built with React components, Vinext, Vite, and a Cloudflare Worker-compatible runtime. Cloudflare D1 stores account and session records. The product uses a replaceable analysis-provider interface so the deterministic local provider can later be exchanged for a reviewed server-side GPT-5.6 integration.

The demo repository index contains curated files, symbols, tests, documentation, and snapshot metadata. During analysis, DevRelay sanitizes the escalation, ranks repository evidence against the report, and constructs a structured hypothesis and ticket. This keeps the demonstration reproducible and allows judges to test the complete workflow without supplying credentials or granting repository access.

Area Technology Language TypeScript 5.9 UI React 19 and App Router-compatible components Runtime Vinext, Vite, and Cloudflare Workers Database Cloudflare D1 Authentication Web Crypto PBKDF2-SHA-256 and server-managed sessions Testing Node test runner through tsx Code quality ESLint and Prettier Hosting OpenAI Sites with Cloudflare-compatible output How we used Codex and GPT-5.6 DevRelay was developed through an AI-assisted engineering workflow in which GPT-5.6 and Codex played complementary roles. A human collaborator retained ownership of the product direction, reviewed the generated work, tested the application, and made the final decisions.

GPT-5.6 GPT-5.6 helped turn the initial product idea into a concrete support-to-engineering workflow. It contributed to product discovery, information architecture, feature boundaries, interface language, privacy controls, uncertainty labeling, and human-approval requirements. It was also used to challenge assumptions, identify missing states and edge cases, and communicate the product to both technical and nontechnical audiences.

Codex Codex worked directly in the TypeScript codebase. It inspected the repository, implemented the React experience and typed domain models, added the D1 schema and authentication routes, built session handling and responsive styling, and created focused regression tests.

Codex was also used during production debugging. It analyzed deployment logs, traced a hosted authentication failure to the Worker runtime's supported PBKDF2 iteration limit, updated the cryptographic policy, verified sign-up and sign-in against the deployed database, and helped republish the repaired application.

Throughout development, Codex ran formatting, type checking, linting, automated tests, and production-build validation. Its changes remained scoped and reviewable rather than being accepted without inspection.

GPT-5.6 and Codex were development collaborators. They are not runtime dependencies in the current deterministic demo, and the application does not imply that live model analysis is occurring when it is not.

Challenges we encountered Grounding a ticket without overstating certainty Repository matches can suggest where an issue lives without proving a root cause. DevRelay therefore separates cited findings from hypotheses, displays confidence explicitly, and uses uncertainty language instead of presenting an inference as fact.

Protecting customer and repository data An escalation may contain credentials, personal information, or raw logs. The workflow needed a clear boundary before analysis or export. DevRelay sanitizes common sensitive patterns, limits repository excerpts, excludes raw logs and attachments from exports, and treats repository access as read-only.

Building authentication for the deployed runtime Authentication worked locally but initially failed in the hosted Worker environment because of a PBKDF2 runtime limit. Production logs helped isolate the problem. The hashing configuration was adjusted to the maximum supported iteration count, after which account creation and sign-in were verified against the deployed D1 database.

Creating a complete demo without external credentials Judges need a reliable path through the product. A deterministic provider and curated repository snapshots make the workflow immediately testable while preserving an interface that can support a future server-side model adapter.

Accomplishments we are proud of Built an end-to-end escalation workflow rather than a standalone ticket-generation screen

Connected every proposed engineering finding to reviewable repository evidence

Made human review and approval mandatory before handoff

Added persistent authentication and revocable server-side sessions

Designed a deterministic, credential-free demo that judges can run consistently

Added focused tests and production validation across security, redaction, workflow, generation, and exports

Diagnosed and repaired a real deployment-specific authentication failure

What we learned The largest lesson was that useful engineering automation depends on boundaries as much as generation. A ticket becomes more trustworthy when the system shows its evidence, distinguishes facts from hypotheses, protects sensitive context, and lets a human decide what leaves the workspace.

We also learned that deployment constraints can invalidate assumptions that appear safe locally. Testing authentication against the actual Worker runtime and D1 database revealed an issue that code review alone did not expose.

Finally, using Codex effectively required clear product constraints, small reviewable changes, and continuous verification. The strongest results came from treating generated code like any other contribution: inspect it, test it, and confirm it against the running product.

Security and privacy boundaries Common API keys, bearer tokens, passwords, secrets, and email addresses are removed from submitted report text before demo analysis.

Repository excerpts are sanitized and limited to 420 characters.

Environment files and credentials are excluded from the repository snapshot model.

Raw customer logs and attachments are excluded from Markdown and JSON exports.

Root-cause statements include a confidence score and a hypothesis disclaimer.

Repository analysis is read-only; it does not clone, execute, edit, or commit code, and it does not open external issues.

External handoff requires an explicit user action and remains simulated in demo mode.

These controls demonstrate the intended product boundary. They do not replace a production security review, tenant authorization model, audit log, retention policy, rate limiting, or data-loss-prevention program.

Demo walkthrough Create an account or sign in.

Open escalation ESC-1042 from the dashboard.

Compare the original customer report with the repository analysis and cited evidence.

Open the engineering ticket and edit a section in the review pane.

Copy the ticket or export it as Markdown or JSON.

Approve the ticket, then explicitly mark it as sent to engineering.

Create a new escalation to test intake validation, attachments, analysis, and ticket generation.

Visit Repositories and Settings to review evidence and provider boundaries.

Run DevRelay locally Requirements Node.js 22.13 or newer

npm 10 or newer

Install and start npm install npm run dev Open the local URL printed by the development server. Create an account from the sign-up page, then use the included demo records to explore the workflow.

The local Cloudflare runtime provides the database binding declared in .openai/hosting.json. Authentication tables are initialized through prepared D1 statements when first needed. No environment variables are required for the deterministic demo.

Validate the project npm run validate Individual checks are also available:

npm run format npm run typecheck npm run lint npm run test npm run build Environment configuration Copy the example file only when adding future integrations:

cp .env.example .env.local Variable Required Purpose NEXT_PUBLIC_AI_PROVIDER No Defaults the interface to demo; secrets must never be stored in a NEXT_PUBLIC_ variable. OPENAI_API_KEY No Reserved for a future reviewed server-side OpenAI adapter. OPENAI_MODEL No Reserved model override for a future server-side adapter. GITHUB_APP_ID No Reserved for a future read-only GitHub App connector. GITHUB_PRIVATE_KEY No Reserved server-side GitHub App credential. GITHUB_WEBHOOK_SECRET No Reserved server-side webhook-verification secret. The settings screen does not persist or transmit a browser-entered API key. Live-provider selections return a configuration error until a reviewed server-side adapter is implemented.

Repository structure app/ api/auth/ Authentication routes login/ and signup/ Account-access pages page.tsx Protected application entry components/ auth-page.tsx Shared authentication experience escalation-engineer-app.tsx Product screens and interactions data/ demo-data.ts Repository snapshots and escalation fixtures db/ index.ts D1 access and schema initialization schema.ts User and session schema lib/ auth.ts Password hashing, sessions, and user lookup repository-analysis.ts Evidence ranking and hypothesis construction security.ts Redaction and excerpt limits ticket-generation.ts Ticket and export generation validation.ts Intake validation workflow.ts Status-transition rules services/ ai-provider.ts Provider interface and deterministic adapter tests/ Authentication, generation, and workflow tests types/ domain.ts Product domain models worker/ index.ts Cloudflare-compatible application entry Current limitations Escalation workflow state is session-local and resets on refresh; user accounts and login sessions are persistent.

Repository content comes from curated demo snapshots rather than a live GitHub or GitLab installation.

The deterministic provider does not call a large language model at runtime.

Attachment contents are not uploaded, parsed, or retained.

Jira, Linear, and GitHub delivery uses copy and download flows rather than direct issue creation.

Organizations, roles, rate limiting, password recovery, MFA, audit logs, and account administration are not yet implemented.

Status history, comments, assignments, service-level agreements, and ticket revisions are not persisted.

What's next Persist escalations, analyses, evidence, revisions, and status history in tenant-aware D1 tables.

Add organizations, role-based access control, password recovery, optional MFA, rate limiting, and an append-only audit log.

Add a read-only GitHub App with allowlisted repositories, pinned references, secret scanning, and incremental indexing.

Implement a server-side GPT-5.6 adapter with structured-output validation, timeouts, cost controls, and prompt-version observability.

Add attachment malware scanning, text extraction, retention controls, and customer-data classification.

Add permissioned Jira, Linear, and GitHub delivery with field mapping, idempotency, and reconciliation.

Expand browser-level accessibility and regression testing across intake, analysis, editing, approval, and export flows.

Built With

Share this project:

Updates