A clipping becomes a ticket
Any scratchpad note can now be raised as a Zammad ticket in one press, filed under the client organisation the note came from. The preview shows where it will land before anything is written, and the note keeps the ticket number as a link.
The Zammad connector files four things on its own: a honey account that was used, a drive that says it is dying, a malware detection the analyser believed, and a machine that fell through the health threshold. Those are events, and the connector raises them because a technician should not have to notice them.
Most of what a technician actually wants in the helpdesk is not an event. It is the paragraph they read in an analysis at ten past ten, clipped into the scratchpad because it mattered, and then had to retype into a ticket at half past. That retyping is gone.
Press the ticket icon
When your Zammad is connected and a group has been chosen for tickets, every note in the scratchpad drawer and on the scratchpad board carries a small ticket icon. Press it and Wegweiser shows a preview: the title the ticket will have, the organisation it will be filed under, and the queue and instance it is going to. Nothing is written until you confirm.
The title is the note's own heading if you gave it one, otherwise the first line of the clipping. A note clipped from a device page is prefixed with the device name, because a queue of forty tickets is scanned rather than read.
The body is the clipping itself with its line breaks kept, who raised it, what it is about, and a link straight back to the page it was clipped from. Once the ticket exists the note shows its number as a link into Zammad. One note is one ticket; the icon does not come back.
The organisation is worked out, not asked for
A scratchpad note already knows what it is about. It was clipped from a device, or a group, or an organisation page, and it remembers which. A device belongs to an organisation and so does a group, so the ticket is filed under the right client because the note remembered where it came from. You confirm rather than pick.
If that organisation was imported from Zammad, the ticket lands under the Zammad organisation it came from, filed for that organisation's first active contact, and the preview names the contact. That is how Zammad works: a ticket belongs to a customer and the organisation on it is the customer's, so an organisation with no contact in Zammad has nowhere to put a ticket. In that case, or when the organisation was created by hand in Wegweiser and has no Zammad counterpart, the preview says so: the ticket will carry the organisation's name and no organisation, because guessing is how a ticket ends up in the wrong client's queue. A note typed into the drawer with no page behind it is filed without an organisation, and the preview says that too.
The same rule now applies to the tickets the connector raises on its own. A ticket that Zammad refuses is logged with Zammad's own reason rather than a bare status code. And the organisation import now links an organisation that already exists in Wegweiser under the same name instead of creating a second one, so the tickets end up under the organisation your devices actually belong to.
The switches in the wizard do not apply here
The Zammad wizard has two switches that keep the connector honest: a tenant-wide one that lets it write into your helpdesk at all, and a per-organisation opt-in so an imported organisation is visible before it is ticketed. Both exist to stop software writing into a live queue unprompted.
A technician choosing to raise one ticket from something they chose to clip is the opposite of unprompted, so neither switch is consulted. A connection and a group are the only requirements, and any role can do it, because raising a ticket is ordinary work rather than a settings change.
The ticket is also kept apart from the connector's own ledger. The hourly sync closes every ticket it opened whose condition it can no longer see; a note is not a condition, and a manual ticket filed in that ledger would have been closed as resolved an hour later. It lives on the note instead, and the only thing that ever touches it is the person who raised it.
Also shipped since Sunday
Dashboard notices say what was fixed. A notice that reports a repaired fault now names the fault and the repair rather than carrying advice written for a different day, and the sentence meant for your client is produced separately from the one meant for you.
No model call waits forever. Every AI provider call now has a timeout, a failed call says which provider failed and why, and a reply with no completion in it is reported as that rather than as a blank answer. The chat no longer re-sends a message when the server answers with an error.
An investigation that runs out of time stops cleanly. The time limit interrupts the tool loop instead of arriving as if it were a tool result, so a long investigation ends with a report of what it managed rather than a confused final step.
A timed-out Lynis audit takes its whole process group with it, and the journal verification that was hanging on one host is skipped. This is agent 0.3.100.