FeedbackMesh

The missing harness between user reality and AI-native software automation.

Modern automation already handles issue -> code -> PR -> review. FeedbackMesh fills the missing upstream step: turning noisy user feedback and runtime pain into decision-ready GitHub issues that agents and engineering systems can actually execute on.

Vision · Quick Start · Hosted Agent-First · GitHub App Setup · Architecture · API Contract · Live E2E

FeedbackMesh is built for small web application teams and independent developers who already have users, already ship on GitHub, and increasingly want AI systems to participate in the whole software loop.

If code generation, PR drafting, code review, and issue execution are already becoming automatable, the bottleneck shifts upstream. Most teams still have no reliable bridge from raw user pain to machine-actionable engineering intent.

FeedbackMesh is that bridge.

It turns user pain, runtime friction, and product ambiguity into evidence-backed cases that are clean enough for GitHub workflows, maintainers, and coding agents to act on with confidence.

FeedbackMesh can also be understood as:

• an AI-native feedback-to-issue harness
• a GitHub-native case intelligence layer
• an upstream issue generation layer for coding-agent workflows
• a user feedback aggregation system for modern web products

The product goal is still operationally simple:

• connect to an existing web app fast
• keep setup close to one-click where possible
• let a GitHub App handle publication and maintainer workflow with minimal operator friction
• expose enough structure that a coding agent can install and use it correctly with very little guesswork

Small-team repo-local path:

npm run fm:init
npm run fm:doctor
node scripts/feedbackmesh_cli.mjs verify
npm run fm:start

Agent-friendly setup contract:

• feedbackmesh.agent.json
• feedbackmesh.integration.json
• signalforge.agent.json
• signalforge.integration.json
• AGENT_README.md
• node scripts/feedbackmesh_cli.mjs manifest
• node scripts/feedbackmesh_cli.mjs integration
• node scripts/feedbackmesh_cli.mjs scaffold browser-preset --json
• node scripts/feedbackmesh_cli.mjs doctor --json
• node scripts/feedbackmesh_cli.mjs verify --json

Plug in fast. Publish cleanly. Keep the decision loop in GitHub.

Project Status

• live GitHub App publication and webhook decision sync verified
• repo-local CLI for sf:init, sf:doctor, verify, and sf:start is in place
• setup-stage diagnostics, repo-aware GitHub App installation discovery, and machine-readable readiness output are implemented
• hosted setup sessions and agent-readable onboarding contracts are available through the API
• the hosted deployment now serves a real post-install landing page at GET /setup for GitHub App Setup URL redirects
• the hosted Agent-First flow at https://feedbackmesh.launchhub.icu has been exercised end-to-end through session creation, binding confirmation, first submission, first publish, and republish idempotency on 2026-06-09
• adapter-first integration path exists for existing web apps
• current maturity target is serious small-team adoption, not demo-only positioning
• npm test passes in a normal unrestricted environment; several build, lint, and typecheck scripts are still placeholders and are the main remaining engineering-surface gap

Trust signals:

• Live E2E Verification
• Omni Lingua Case Study
• Omni Lingua Agent-First Closure
• Reader Feedback Examples
• Quick Start
• Hosted Agent-First Flow
• Deployment Guide
• One-Click Adoption Plan
• Release Notes
• Changelog
• Security Policy
• Support
• License

Compatibility note: the older sf:* scripts, signalforge_*.json files, SIGNALFORGE_* env vars, and X-SignalForge-Project-Key header still work and remain the authoritative legacy protocol surface for now.

Why FeedbackMesh Exists

The software loop is being automated from the middle outward.

Teams already have serious momentum around:

• issue-driven coding agents
• automated PR generation
• AI-assisted code review
• GitHub-native execution workflows

But those systems still depend on one fragile assumption:

that a high-quality issue already exists.

In practice, that assumption fails constantly. The real input is messy:

• confused user feedback
• repeated complaints with different wording
• support conversations with partial context
• runtime failures that never become coherent product work

FeedbackMesh exists to make that upstream layer usable.

The ambition is not to become another inbox.

The ambition is to become the feedback harness that makes the rest of the software automation chain meaningfully more effective.

If someone is searching for tooling around AI-native feedback triage, GitHub issue automation, user feedback aggregation, or case intelligence for coding agents, this is the category FeedbackMesh is built for.

The Missing Layer In The AI-Native Stack

Most AI-native engineering stacks are getting strong at the downstream half:

• GitHub issue intake
• code generation
• PR creation
• review automation
• execution harnesses

What is still weak is the upstream half:

• messy user complaints
• vague support threads
• repeated "something feels broken" reports
• runtime pain disconnected from product context

FeedbackMesh sits exactly in that gap.

It turns user reality into a smaller number of structured, evidence-backed cases so the rest of the automation stack has something clean to act on.

user feedback + runtime pain
-> FeedbackMesh intake and aggregation
-> decision-ready case
-> GitHub issue
-> coding agent / maintainer workflow
-> shipped fix

Integrate	Publish	Operate
Add FeedbackMesh to an existing web app through the adapter, widget, or direct API without reshaping the product stack.	Aggregate repeated reports into one case, then publish only when policy says the issue is ready.	Install the GitHub App, bring the bot into the repo, and keep maintainer actions inside the normal GitHub workflow.

Why This Category Matters

If the feedback-to-issue layer is weak, the entire AI-native delivery chain downstream becomes brittle.

A coding agent can fix a well-scoped issue.

It cannot reliably rescue a chaotic stream of raw user complaints unless something upstream performs:

• aggregation
• normalization
• evidence synthesis
• policy-gated publication

That is the category FeedbackMesh is trying to define clearly: not helpdesk software, not generic issue tracking, but the harness that converts product reality into automation-ready engineering objects.

Why Teams Adopt It

Most small product teams already have enough signal.

What they usually lack is a lightweight way to turn that signal into clear engineering action without:

• building an internal triage tool
• buying a heavyweight support suite
• forcing engineers into another dashboard

FeedbackMesh is meant to close that gap.

The bigger bet is that this becomes foundational infrastructure for AI-native product teams: not another dashboard, but the feedback harness that feeds the rest of the software automation chain.

Core Experience

1. Fast Integration For Existing Web Apps

FeedbackMesh is designed to sit on top of an existing app, not replace it.

You can use:

• @feedbackmesh/adapter for application-side integration
• the feedback widget for fast end-user capture
• direct API ingestion for custom pipelines
• runtime signal ingestion alongside tools like Sentry or GlitchTip

2. Near One-Click Operator Flow

The operational goal is to feel close to "plug it in and go":

• run the API with repo-level env
• connect the app through the adapter
• install the GitHub App into the target repo
• let FeedbackMesh publish and sync decisions through the bot workflow

For small teams, that matters more than deep admin surfaces.

3. Mature GitHub App Workflow

FeedbackMesh is intentionally GitHub-native.

The long-term mature path is not "copy tokens around forever."

It is:

• install the GitHub App
• grant the repo access it needs
• let FeedbackMesh publish issues through the app
• let maintainers act through comments and normal GitHub review habits

That is the model we want to make production-ready and boring in the best way.

4. Agent-Friendly By Design

FeedbackMesh is also designed for the way modern teams actually work now: a human or operator often pastes a repo URL into Codex or another agent and expects the system to wire things up correctly.

That is why the repo includes:

• machine-readable integration contracts
• scaffold commands for common integration presets
• a dedicated AGENT_README.md
• repo-local verification commands instead of hand-wavy setup prose

If a product claims to be AI-native infrastructure, it should be installable not only by a careful human operator, but also by an agent working from repo context and a short instruction.

What It Does

• feedback intake for end-user submissions
• runtime signal ingestion and case enrichment
• aggregation-aware triage with stable clustering
• canonical case summaries and evidence rollups
• automatic GitHub issue publication when policy says publish_now
• owner decisions synced from GitHub comments
• context retrieval for follow-up automation and delegation
• adapter-first integration for existing web apps

System Flow

existing web app
-> FeedbackMesh adapter / widget / API
-> aggregated case
-> GitHub App issue publication
-> maintainer decision in GitHub
-> execution / delegation

Quick Start Shape

For most teams, adoption should look like this:

1. run the FeedbackMesh API
2. connect the existing web app through the adapter
3. install the GitHub App into the repo
4. let feedback start flowing into aggregated cases
5. let the bot publish issues and sync maintainer decisions

If you want the shortest path to a working setup, start with:

• docs/quick-start.md
• docs/github-app-setup.md
• npm run fm:doctor

Example Integration

import { createFeedbackMeshAdapter } from '@feedbackmesh/adapter';

const sf = createFeedbackMeshAdapter({
  endpoint: 'https://signalforge.example.com',
  projectKey: 'proj_readerapp',
  appName: 'readerapp',
  environment: 'production',
  release: '1.2.3',
});

await sf.captureFeedback({ body: 'Save button freezes on mobile.' });
await sf.captureError(new Error('reader timeout'));

const unbind = sf.installGlobalErrorHandlers();
sf.mountFeedbackWidget(document.getElementById('sf-root'), {
  defaultOpen: false,
  includeContactField: true,
});

Verified End-to-End

FeedbackMesh has already been validated against a real GitHub App flow:

• deployed behind HTTPS at feedbackmesh.launchhub.icu
• real GitHub App issue publication
• real GitHub webhook delivery
• real owner decision sync from GitHub issue comments back into FeedbackMesh state

Verified flow:

feedback submission
-> case creation / aggregation
-> GitHub App issue publish
-> owner comments /accept or /defer
-> GitHub webhook
-> FeedbackMesh decision record + case status update

See docs/deployment.md for the current hosted reverse-proxy shape, and docs/live-e2e.md for verification details and known gaps.

Why It Feels Different

FeedbackMesh is opinionated about one thing:

the goal is not to create more tickets.

the goal is to create fewer, better decision surfaces.

That means:

• duplicate reports should usually collapse into one case
• issue publication can be automatic
• issue creation is not the same as engineering approval
• maintainers should make one real decision in GitHub, not in a second admin system

The point is not to make the feedback layer louder.

The point is to make the upstream automation boundary finally trustworthy.

What FeedbackMesh Is

• the intake and aggregation layer for AI-native software delivery
• a lightweight feedback ops layer for existing web apps
• a GitHub-native case aggregation engine
• a bot-friendly issue publication and decision loop
• an automation handoff point for agents and workflows

What FeedbackMesh Is Not

• a full support desk
• a full issue tracker
• a replacement for Sentry or GlitchTip
• a heavyweight internal tooling platform

GitHub App Maturity Direction

The GitHub App path is no longer just conceptual.

What already exists:

• GitHub App publisher support
• JWT signing
• installation token exchange
• issue publication through app auth
• webhook-driven decision sync

What we want this to become:

• install the app
• invite the bot into the repo
• configure once
• operate through GitHub with minimal manual setup after that

That is the maturity bar.

Runtime Signals

FeedbackMesh does not try to replace mature exception monitoring tools.

Recommended layering:

• Sentry or GlitchTip for runtime collection
• FeedbackMesh for aggregation, case correlation, publication, and orchestration

Why Now

The industry is rapidly getting good at automating work after a good issue already exists.

The unresolved problem is how to create that good issue from noisy reality, repeatedly, safely, and with enough structure that agents can keep going.

That is the layer FeedbackMesh is trying to make real.

Built For Small Teams

FeedbackMesh is deliberately shaped for the teams that feel this gap most sharply:

• startups with one main web product
• indie developers shipping fast on GitHub
• small product teams that want AI leverage without building a full internal ops stack first

Those teams do not need a giant platform.

They need fast integration, a GitHub-native workflow, and a system that starts converting feedback into better engineering inputs immediately.

Docs

• docs/vision.md
• docs/case-studies/omni-lingua.md
• docs/omni-lingua-agent-first-closure.md
• docs/case-studies/mobile-lookup-friction.md
• docs/case-studies/backend-hang-user-pain.md
• docs/case-studies/reader-feedback-to-case-examples.md
• docs/case-studies/social-snippets.md
• docs/quick-start.md
• docs/one-click-adoption-plan.md
• docs/object-model.md
• docs/api-contract.md
• docs/github-flow.md
• docs/github-app-setup.md
• docs/deployment.md
• docs/privacy.md
• docs/mvp.md
• docs/architecture.md
• docs/roadmap.md
• docs/llm-triage.md
• docs/live-e2e.md

LLM Setup

FeedbackMesh can run in two modes:

• heuristic fallback only
• DeepSeek-backed LLM triage

Set these env vars to enable DeepSeek:

DEEPSEEK_API_KEY=...
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_MODEL=deepseek-v4-flash

If no key is configured, FeedbackMesh continues using heuristic triage.

For local startup with a repo-level .env, run:

node scripts/start_api_with_env.mjs

Repository Scripts

• node scripts/start_api_with_env.mjs
• node scripts/run_readerapp_feedback_sample.mjs
• node scripts/run_github_issue_publish_e2e.mjs
• node scripts/run_github_app_publish_e2e.mjs