How feedback works

Three channels, three different jobs. Pick the one that matches what you have. ← WebX11 · Report a problem →

Which one do I use?

Something breaks → /stear

You have: something you can describe — a 403, a blank page, a wrong number.

You get back: a stored report with an RPT- id. Log in and open My reports on the same page — the reply appears there, in writing.

A question or a remark → `feedback`

You have: a question about what the AI just did, or a request to change it.

You get back: an answer in your terminal, usually within 5 minutes. Nothing is stored as a report.

Nothing at all → say nothing

You have: a page that threw a JavaScript error.

You get back: nothing — the debug supervisor files it automatically with version and stack, and the daily triage run picks it up.

A request that failed → usually nothing

You have: "fetch failed", "load failed", "network error", a timeout.

You get back: these are counted, not filed — the server keeps a per-day counter per endpoint, so a broken route is visible without a report for every dropped packet. If one page fails every time, send it through /stear: a report written by a person is always filed.

The newOS4 command

Say something

feedback the download link 403s on my phone

Alias: hermes. Sends one line to the operator channel and prints the message id. It is a conversation, not a ticket — no email, no account, no status to check. The thread is kept on the server, keyed by your browser token, so it survives a reload and also appears in the operator's dashboard; hermes-reset starts a fresh one but does not delete the old.

Starts with a word the terminal treats as a subcommand (for example list)? Put -- in front, and the whole line is sent as a message:

feedback -- list is broken on mobile

Read the answer

feedback-inbox

Alias: hermes-poll. Prints anything the agent sent since the last check. Replies also land on their own every ~30 s while the terminal is open, so you rarely need this.

Start clean

hermes-reset

There is no feedback-reset command — the reset is hermes-reset. It mints a new browser token, which is a new thread. Your old thread is not deleted, it is just no longer shown.

When to expect an answer

Terminal (feedback): the auto-reply loop runs every 5 minutes. A message sent and never answered usually means the agent judged it as no-action-needed, not that it was dropped. If it matters, send it through /stear instead — that channel is stored and gets a written reply.
/stear: replies are written by a human operator, never automatically. The day's runs are in the morning — triage at 07:15, approved fixes shipped at 08:30 — so a report filed in the afternoon or evening is normally picked up the next morning. The report is never deleted, so the reply is still there next week.
Automatic reports: no reply is sent to you at all. The ones that are filed show up in the operator's daily triage digest; reports whose errors are all network failures are counted instead of filed.

What is actually sent

Channel	Payload
`feedback` (terminal)	Your text + a random 64-hex browser token that identifies the thread. No account, no email, no page URL.
`/stear`	Category, message, optional email, the page you were on, and a truncated context blob (≈1 KB) with version + user agent. Attached to your account if you are logged in, otherwise anonymous.
Automatic (debug supervisor)	Error message, stack trace, page URL, newOS4 version, user agent. The server caps a report at 512 KB and accepts 5 per IP per 10 minutes. An identical error — same title, same messages, same version — inside 24 hours is merged into the existing report instead of creating a second one. A report whose only errors are network failures is not filed at all; it is counted per endpoint per day. Reports filed by the terminal's `feedback` command are not part of any of this — they carry only your text and the thread token.

Never send: passwords, session tokens, API keys, card numbers, or anything you would not want to read in a triage digest. Both channels are readable by the site operator. An automatic report carries the error message, its stack, the page URL, the newOS4 version and your user agent — not the text that was on your screen. Text you type into a report or into feedback is stored as you wrote it.

Writing a report that gets fixed

What you did — the exact command or the exact link you tapped.
What happened — the text of the error, not "it doesn't work".
Where — page URL and, if you know it, the version from the footer (v4.6.x).
How often — every time, or once. "Once, after a reload" changes the diagnosis.

One defect per report. A report that lists six things tends to get one of them fixed.

What happens after you send it

The item lands in the operator's review dashboard (/admin/feedback.html) — for a /stear report it is a row in the feedback table; for a terminal message it is a chat thread; for a crash it is an automatic report.
The daily triage run (07:15) groups it with reports of the same cause and tags each record real, noise or self-referential. Tagging is not a decision — the next step decides.
An autonomous reviewer takes a first pass twice a day, at 07:40 and 19:40. It decides only what it can prove: a duplicate, or an identifier that is provably gone from the shipped code (git log -S shows the commit that removed it), is resolved; pure noise is rejected; a report whose error is still in the shipped code is approved — at most two a day. Reports written by a person, and plans, are never decided by it. Every automatic decision carries its reason, and the operator can override any of them with one click.
Real defects get a plan with a root cause (file:line) and, once approved, a fix in the next version of newOS4 — the implementer runs at 08:30.
The reply — where a reply exists — appears in My reports (/stear) or in the terminal (feedback-inbox).

WebX11 · feedback guide · channels: feedback (terminal) · /stear (form) · automatic reports (debug supervisor). Admin view: /admin/feedback.html. Back to webx11.duckdns.org.