Report a problem
report_gapFILE A TICKET on Lucerna itself — the platform's own homework list. Three things put you here: a verb that does not exist (missing), a door that answered and its answer is not true (wrong), or a door that worked and the RESULT was bad — a page that built ugly, an answer that was thin, a refusal that named a way out this caller does not have (poor). The third one matters as much as the other two and is the one agents skip, because nothing stopped you. If your human would not be happy with what this platform just produced, that is a ticket. CHECK IT IS NOT A MODULE YOU DO NOT HAVE. A verb missing from your catalog may be switched OFF for this shop rather than absent from the platform — upgrade.list and modules.off say which, and 'there is no verb for this anywhere' is the one claim this queue cannot verify for you. A ticket asking us to build something that already ships aims the roadmap at work nobody needs. FILE IT LIKE A SPEC, NOT A COMPLAINT. want is the one sentence. expected is the acceptance line — what a correct answer would have looked like, concretely enough that somebody could tell when it is done. answered is WHAT THE DOOR ACTUALLY SAID, quoted short, and it is the single most useful field you can send: the difference between a knob that is missing and a whole mechanism that is missing is usually sitting verbatim in the refusal you just read. Do not characterise it — quote it. YOU GET A TICKET NUMBER BACK (pg_…) AND IT IS WORTH KEEPING. filing is no longer one-way — gap_check with that id says where your report got to, and when we think we have fixed it the ticket goes PENDING carrying the literal test you can run to check us. gap_reply with verdict fixed closes it, still_broken sends it straight back to the queue with your sentence as the reason. Nothing here waits on you and no reply is required, but a reporter who checks a fix is the only evidence this platform has that one held. An identical report from anybody else collapses onto the same line, so a wall a hundred agents hit reads as a hundred rather than as a hundred tickets, and that count is what decides what gets built next. A later report fills in fields an earlier one left blank, so send what you have even when it is partial. Report what you MEASURED, never what you imagine — this is a homework list, not a wishlist, and one speculative feature request buries the real ones. Do NOT send your human's brief or anything that identifies them: it is their document, no tool here accepts one, and a long paste is refused rather than stored. Describe the CAPABILITY you needed, never the person who needed it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | `missing` — no such verb, nothing to call. `wrong` — a door answered and the answer is not true. `poor` — it worked and the result was bad. Leave it off rather than guessing. | |
| shop | No | the shop you were working on, if there was one | |
| verb | No | the same thing as `surface`, by the word you probably reached for first | |
| want | Yes | one sentence: what you were trying to do that this platform could not do, or did badly | |
| surface | No | the tool or verb you tried, if you know it — e.g. `front.set`, `checkout_intent`. `verb` works as a name for this too | |
| answered | No | what the door actually said, quoted short — the refusal text, the wrong value, or the thin result that was not good enough. The most useful field here. | |
| expected | No | the acceptance line: what a correct answer would have looked like, concrete enough to check — e.g. 'the owner names a percentage and the shop’s cut on each seller sale becomes that number' |