PROJECT · goquest

goquest

Private

AI-agent dedicated ticket system

This is currently a private project. The overview below is high-level — reach out for adoption inquiries.

A lightweight, fast ticket management service for the neunexus ecosystem, designed for AI agent workloads.

Flow overview

goquest's own steps flow left to right — click a node for detail, drag to pan, scroll to zoom. The tinted nodes are other services.

Core Features

  • Ticket CRUD and a state machine built for AI agent workloads
  • Event-driven flow — agents pick up tickets, act, and update status
  • Routes work from PM automation to domain tasks (infra · data · code · monitoring · knowledge)
  • Integrates tightly with the neunexus orchestration ecosystem

Why goquest

Where teams actually reach for it

nuclex PM bot

› Can the PM bot delegate sub-tickets and track completion through events?

GOQUEST RESPONSE

When nuclex creates domain sub-tickets through the goquest REST API (retry-idempotent via Idempotency-Key), goquest.tickets.* events fire at every lifecycle step, and the Nuclex emitter relays ticket.completed/failed/pending_approval onto nuclex.events. Once every parent_id sub-ticket completes, the parent ticket completes automatically.

POST /tickets (Idempotency-Key) → domain=infra → Redis Streams → Nuclex emitter

Orchestration lineage recorded via refs (gopedia L1 doc id) + the parent_id chain

Repo developer

› Can branch/PR events move a ticket's state automatically?

GOQUEST RESPONSE

goquest parses push/create/pull_request from an HMAC-verified GitHub webhook and auto-links branches/commits/PRs to a ticket by matching title_name. A branch or open PR moves the ticket to in_progress; a merged PR moves it to completed, and the PR's source/target branches are stored.

GitHub webhook (HMAC) → title_name match → branch/PR link → automatic state transition

Backed by the repo registry (POST /vcs/repos) and the cmd/vcs-reconcile manifest

Helpdesk agent

› Can customer auth and internal/public comments be split safely?

GOQUEST RESPONSE

The customer authenticates with a magic-link token (ct_*) bound to their ticket, while agents write and publish internal vs. public comments separately. Macros and templates automate repeat responses, and every action lands in an append-only audit log.

magic-link ct_* token → internal/public comment → SMTP ticket-replied

Backed by helpdesk KPIs and the audit log

TOJI security operator

› Can we separate view and manage permissions and roll out enforcement safely, shadow → enforce?

GOQUEST RESPONSE

Reads go through the RequireTicketView gate; lifecycle changes like PATCH/DELETE/approve go through RequireTicketManage — a dual gate. SPICEDB_ENFORCE=false (shadow, check-only) lets you observe safely before flipping to true (enforce); production runs enforce=true.

SpiceDB RequireTicketView + RequireTicketManage · SPICEDB_ENFORCE

Backed by SpiceDB's view/manage dual gate and the shadow/enforce rollout

Related scenarios

Related Projects

Architecture detail Contact