/feedback

name: feedback
description: Report a Dex bug to the Dex team with zero homework — Dex investigates locally, builds a privacy-safe report, shows it to you (or auto-sends if you've chosen that), and tracks the ticket until it's fixed. Use when the user says "report this", "send this to the Dex team", "file feedback", "/feedback", asks "what happened to my bug report", or accepts Doctor's offer to report a Dex bug. Not for capturing ideas about your own vault or workflow; use the improvements backlog for those.

/feedback — concierge bug reporting

Turn "something in Dex is broken" into a high-quality report on the Dex team's desk, with the user doing nothing but approving. Contract: `docs/feedback-loop-contract.md`.

Cardinal rules (read every time)

1. **The conversation is never a source.** A report may contain ONLY the allowed ingredients: Dex version, feature/skill name, what happened vs what was expected (phrased as Dex mechanics), error text and stack traces (Dex's own code paths), machine-state facts (OS, host app, feature health — never config values or file contents), investigation findings as mechanisms and counts ("checked 5 lines, 0 had task identity" — never the lines themselves), and a note the user types. Nothing about the user's work, people, meetings, or personal life — even if it feels relevant. If a fact can't be phrased without private content, leave it out. 2. **File paths:** Dex's own code paths (like `core/utils/doctor.py`) are fine. Paths to the user's notes are not — describe the folder role instead ("a person page under the People folder"). 3. **Show-before-send is governed by the trust dial** (`feedback` → `review_mode` in `System/user-profile.yaml`):

• `always-review` (default): show the exact draft, wait for a clear yes.

The user may edit anything first.

• `auto-send`: send without asking, then confirm in one calm line and offer

"say 'show it' to see exactly what went."

• **The first report is always reviewed** regardless of the dial (no ticket

files under `System/.dex/feedback/` means first report).

• **Answers to questions are always reviewed** regardless of the dial.

4. **Never send without the script.** All sends go through the client script so every attempt lands in the local receipt log (`System/.dex/feedback-log.jsonl`).

Filing a report

1. **Establish the facts.** From the conversation and quick local checks:

• Dex version: read `version` from `package.json` at the vault root.
• Feature: which skill/command/automation misbehaved.
• What happened vs expected, in one or two Dex-mechanics sentences.
• Error trace: if an error or traceback was captured this session, include it

whole (it contains only Dex code paths). Do not reconstruct one from memory. 2. **Investigate locally before sending** (this is what makes reports actionable). Debug like an engineer with full local access, then send the *mechanism*, not the data. Examples of good investigation findings:

• "Focus items in the daily plan are missing task identity — checked 5 lines, 0 had it."
• "The sync automation is installed but not loaded; last successful run July 30."
• "The person index exists but has not been rebuilt since the folder was renamed."

Keep it to what you verified, with counts. Never quote vault content. 3. **Machine state.** Assemble a small `machine_state` object from cheap facts: `os` (from `uname -s`, lowercased), `host_app` (e.g. claude-code), and — when `System/.dex/smoke-last-run.json` or a recent Doctor report exists — a `features` map of health states (values like ok/off/broken only). Skip anything you can't check cheaply; an empty machine_state is fine. 4. **Write the draft** to a temp file (e.g. `/tmp/dex-feedback-draft.json`):

   {
     "dex_version": "<from package.json>",
     "feature": "/process-meetings",
     "summary": "<what happened vs expected>",
     "error_trace": "<verbatim, optional>",
     "machine_state": { "os": "darwin", "host_app": "claude-code" },
     "investigation": "<mechanism findings, optional>",
     "user_note": "<only if the user typed one>",
     "review_mode": "<the user's dial setting>"
   }

The script adds the timestamp and failure fingerprint itself. 5. **Apply the trust dial** (cardinal rule 3). For review: show the draft's fields exactly as they will be sent, in a readable form, and ask once — "Send it? You can edit anything first." Apply any edits to the draft file. 6. **Send:**

   python3 .claude/skills/feedback/scripts/feedback_client.py report --file /tmp/dex-feedback-draft.json --vault "$VAULT_PATH"

• Exit 0: confirm with the ticket reference the script printed, e.g.

"Sent — reference DEX-142. I'll tell you when there's news."

• Exit 2 (CONNECTION NEEDED): the terminal isn't linked yet. Show the

script's instructions — the user opens the connect page, signs in, creates a code, and you run the `link` subcommand with it. This is a one-time, ~30-second step; after linking, send the report without re-asking.

• Other exits: relay the script's plain-language message; don't invent detail.

7. **First-approval upgrade offer.** If the user approved without changing anything and their dial is `always-review`, offer once: "Want me to just send future reports automatically? You can switch back anytime." If yes, set `feedback.review_mode: auto-send` in `System/user-profile.yaml`. Never re-offer in the same vault after a no (note the no in the user's preferences).

Checking status

When the user asks about their reports (or after filing):

python3 .claude/skills/feedback/scripts/feedback_client.py status --vault "$VAULT_PATH"

Relay the script's list plainly. Statuses mean: RECEIVED (on the team's desk), INVESTIGATING (being worked), NEEDS INFO (a question is waiting — offer to answer it), FIXED in vX (suggest /dex-update