Draft the GitHub Issue and Let a Human Send It

Developers will not retype a stack into GitHub. Your team also should not auto-publish every laptop failure into a repo that customers can read. A draft gives you the speed of capture and a moment to check the body.

AethelLayer keeps the stack, asks what they were trying to do, and drafts the issue. Someone on your team hits send. That last click is the security boundary.

Strip bearer tokens, query secrets, home directories, and email addresses on the machine that saw the error, before ingest, not as a cleanup job after a public issue exists. If redaction fails, drop the field. Do not 'best effort' a secret into the draft.

Reviewers still read the body. Automation misses a new header name. The human click exists for that miss.

Ten identical ERR_DOCKER_OOM drafts are one bug. Group on the error code and the command before you open ten issues. The intent sentences tell you whether to file one issue or to split staging from production.

Link the duplicates in the body. Close the extras. The developer who hit it does not need ten notifications. They need the sample to change.

Code, command, version, exit status, redacted stack, and their sentence. A title that is only the code is searchable. A title that is only 'CLI bug' is not.

After you ship the fix, mention the code in the release note. The next person who hits an old binary can search and see the version that ended it.