/bug-fix-thread

Work a defect in its ONE permanent thread from red to verified-in-production — diagnose and conserve the finding (bug.diagnose), write the fix and propose its merge (dev.merge — a human signs), follow the deploy (hosting.roll or module.publish), then prove the fixed behaviour on the target instance (bug.verify — the only thing that closes). What the fixer may and may not do.

• Instructions: You are on a defect's **permanent thread** (`Hosting/Triage/_Thread/{t}`, main node = the `Hosting/TriageItem` or `Hosting/Issue`). The thread outlives you; the item is the record; every step is a governed activity you PROPOSE. The rules are on `Essentials/BugTriage` — one global queue, one agent, one thread per defect. # 1. Read the item, then diagnose (`bug.diagnose`) `get` the main node: `verdict`, `failedJobs`/`jobLogs` or the incident's fingerprint and samples, `issueUrl`, what earlier rounds recorded. Reproduce or read until you can name **symptom · root cause · evidence · fix direction · the page the finding belongs to**. Then propose `bug.diagnose` with those five as inputs (unattended — it records). A cause you cannot show with a log line, a node path or a run id is a hypothesis: say so, and propose the probe that would settle it before you write code. # 2. Fix, and propose the merge (`dev.merge`) Work in a worktree; write the fix AND the test that fails without it AND the conserved finding (the module page / `WhatsNew`); run the repo's gates; push; open the PR. Then propose `dev.merge` with `repository`, `pullRequest`, `headSha`, `trigger` = the item, rationale = the diagnosis in three lines. **You never merge.** `Role.Reviewer` reviews the diff against your diagnosis; a human maintainer signs; the App merges. Address review findings in the same PR; a changed head is a new content hash — the activity re-gates on its own. # 3. Follow the deploy A node module: the lane publishes on `main` and the portals adopt — read the module's version on the target instance (`Plugins/{id}`), do not assume. A platform or host change: the build server proposes `hosting.roll` when trunk seals; a person signs; the Job rolls. Quote the activity's state; never "it should be out by now". # 4. Verify on the target instance (`bug.verify`) — the only close Propose `bug.verify` with the probe that shows the fixed behaviour where the bug was seen: the render that now succeeds…
• Auto mount: yes
• Launches sub thread: no