Day 7 - From request to ticket, automated

End-to-end automation: the ideas form and Admin Help turn submissions into clear tickets, with human review before anything gets built.

Introduction

Day 7 is a special entry: it documents automation that closes a gap the earlier days left open. Someone submits an idea or incident; a developer used to read raw text, rewrite it as a GitHub issue, and only then start implementation. That handoff was the bottleneck.

On 4 June 2026 we wired the full loop in two channels: public feedback on km0digital.com (production) and internal admin Help on a Laravel ecommerce staging stack. Same mental model: queue, autoissue draft, human label, autoagents pickup.

Summary

Before and after

Request: loose message or email → structured JSON in a queue.
Understanding: developer parses raw text → cursor-agent writes a structured .md draft.
Ticket: manual gh issue create → automated issue with clean Markdown body.
Human control: implicit → label waiting for human validation.
Implementation: developer assigns work → human removes the label → autoagents (001 / FEAT) pick up the issue.

The developer no longer opens a raw submission and writes the ticket from scratch. The system enqueues, drafts, and publishes to GitHub in seconds. A human validates or edits by removing the label; then the agent pipeline can implement.

Architecture

Two inputs, one pattern

INPUT
  km0-web:     POST /hooks/ideas        (public /ideas/)
  ecommerce:   POST /api/v1/admin/help  (authenticated /admin/help)
        ↓
  JSON queue (spool / storage)
        ↓
  Immediate trigger (systemd path / queue job)
        ↓
  cursor-agent (--yolo) + autoissue prompt → draft .md
        ↓
  gh issue create --body-file + label waiting for human validation
        ↓
  Human reviews → removes label → autoagents 001 → FEAT → code

Why it fits

A practical pattern for small teams

We were not chasing automation for its own sake. We wanted useful requests to stop dying in a chat thread, an inbox, or someone's memory. The system turns each submission into a readable ticket, with context and scope, in seconds.

Speed: the sender does not wait for someone to find time to write up the incident.
Quality: every draft follows the same shape (what happens, for whom, what is expected).
Control: nothing enters development until a person on the team approves it.
Reusable: the same pattern works for public feedback and internal requests.

For KM0 it is especially apt: we hear from non-technical people and want to treat their input with the same care as a report from an ecommerce admin.

Where it applies

Two entry points, one journey

KM0 users: the Ideas form on km0digital.com. Product suggestions, website improvements, or gaps someone notices while using the cloud.
People running an internal project: the Admin Help screen on an online shop in staging. For when a team member spots a bug or needs a change and wants it logged with a clear trail.

In both cases the journey is the same: form → queue → drafted ticket → human review → implementation. Only the writer and the surface change, not the logic.

Examples

What it looks like in practice

Suppose someone submits via Ideas: “I'd like a button to share blog posts.” Within about fifteen seconds the system produces a titled, structured ticket: what the person asked for, which language they used, which part of the site it touches. It is marked waiting for human validation.

Someone on the team reads it. If the wording is fine, they remove the mark and the ticket joins the automated implementation queue. If it needs nuance (“mobile only”, “WhatsApp icon”), they edit the ticket before approving. No copying the original message by hand.

Another case: a shop admin in staging reports through Admin Help that a product filter does not save correctly. Same mechanics: a clear ticket, a review step, then development. The goal is that nobody has to guess what the sender meant.

People

What automation does (and does not)

The machine drafts and classifies. A person decides. Development agents do not pick up tickets while they are still marked pending validation, so we avoid building on vague messages or noise.

For someone sending an idea, the benefit is simple: write once in plain language and the team receives something actionable. For whoever runs the service, the benefit is no longer being the permanent translator between “WhatsApp message” and “well-written ticket”.

Outcome

What day 7 achieved

The manual step between “someone asks for something” and “there is a ticket that can be implemented” is gone in production (KM0 public ideas) and on the ecommerce staging environment (Admin Help).

The full cycle now works: request, drafted ticket, human validation, and agent-assisted implementation. It was the missing piece to close the loop between listening to the community and shipping changes with judgment.

Series

Days 1–6

Earlier entries cover the stack (OpenCloud, Dex, LDAP, native clients, tutorials, vision). Day 7 adds the feedback loop: try the ideas form or browse day 6 for device onboarding. Questions: get in touch.