adom-wiki discussion create <owner/slug> \
  --title "<short, actionable title>" \
  --category "bug|suggestion|question" \
  --body "<what you want, why, and any links. End with: please close once done.>" \
  --json

adom-wiki discussion list <owner/slug>            # triage your open items
adom-wiki discussion view <id>                    # read it + replies
adom-wiki discussion comment <id> -b "Done in <commit/version>."
adom-wiki discussion triage <id> --status closed  # close when resolved
adom-wiki discussion reopen <id>                  # if it regressed

---
name: wiki-notes-via-discussions
description: How to leave a note, request, bug, or suggestion on an Adom Wiki page you do NOT own. Open a DISCUSSION item (an "open" issue) with adom-wiki discussion create; the owning repo's next agent thread actions it and closes it. Do NOT edit/push to pages you don't own, and do NOT use breadcrumbs for notes (breadcrumbs announce a related add-on you built). Read before leaving any cross-repo note. Triggers: leave a note on a wiki page, suggest an edit, file a wiki bug, request a change, breadcrumb vs discussion, comment on someone's page, wiki issue, close discussion, open issue on a page.
---

# Wiki Notes via Discussions

When you want to tell the owner of a wiki page something: "please link X", "this
is out of date", "here's a bug", "I built a related thing", **you do not edit
their page and you do not use a breadcrumb for it.** You open a **discussion
item** (an issue). It stays **open** until the owning repo's next agent thread
(or a human maintainer) actions it and **closes** it.

## Why discussions, not edits or breadcrumbs

- **Editing a page you don't own** is off-limits: you'd clobber their content and
  bypass review. You only push to repos you own.
- **Breadcrumbs are a different tool.** A breadcrumb is a *trail marker* that
  announces a related thing you *built* (an add-on / bridge / plugin) so it's
  discoverable from their page. It is not a message, a request, or a bug report.
  Using a breadcrumb to "leave a note" is a category error.
- **A discussion is the message channel.** It is a gh-issue-style thread:
  open, discuss, close. Another AI thread that owns the repo can pick it up with
  full context and resolve it. This is how cross-repo, cross-thread work
  coordinates in the Adom ecosystem.

## Leave a note (you don't own the page)

```bash
adom-wiki discussion create <owner/slug> \
  --title "<short, actionable title>" \
  --category "bug|suggestion|question" \
  --body "<what you want, why, and any links. End with: please close once done.>" \
  --json
```

- **Read the `--json` envelope** and confirm `status: ok` plus a returned
  discussion `id`. Do not claim you "left a note" until you have seen that. A
  silent failure or 500 means no note exists.
- Make the title an **action** ("Add a pointer to X", not "X"). Put links and
  rationale in the body. State that it should be closed when done.
- One discussion per concern. Do not dump five asks in one.

## Resolve a note (you DO own the page)

When you own a page, treat its **open** discussions as your inbox:

```bash
adom-wiki discussion list <owner/slug>            # triage your open items
adom-wiki discussion view <id>                    # read it + replies
adom-wiki discussion comment <id> -b "Done in <commit/version>."
adom-wiki discussion triage <id> --status closed  # close when resolved
adom-wiki discussion reopen <id>                  # if it regressed
```

Action it (push the fix to your repo), comment what you did, then **close**.
Leaving resolved items open rots the queue; closing without action loses the ask.

## The loop, in one line

You (do not own it), `discussion create` (opens), owner's next thread, fix +
`comment` + `triage --status closed`. Notes flow between threads as open issues,
not as edits or breadcrumbs.

## Do not

- Do not edit/push to a repo you do not own to "leave a note."
- Do not use `breadcrumb post` for a message/request/bug (that is for announcing
  an add-on you built).
- Do not claim a note was left without reading the `--json` success envelope.