Paste this into the BW Guides session.

---

Picking this up properly — the earlier message reached you from the wrong session, so you were
inferring the ask from a fragment. Both your questions are good ones. Here are the answers, and
the half of the request that didn't make it across.

## 1. Is that the request? Half of it

Yes to a filterable read capability. But the more important half is that **read and write are
currently the same capability**, and that's the part worth fixing while you're in there.

`BW_Guides_Admin::READ_CAP` is `edit_posts` — and so is `BW_Guides_Ajax::CAP`, which gates:

- `bw_guides_save_tags` → `wp_set_object_terms()`, writing **shared** taxonomy terms on the guide
- `bw_guides_save_note` → annotates the guide itself, not a per-user copy
- `bw_guides_check_updates` → runs a full `BW_Guides_Sync()`, which creates, updates and trashes posts

So one capability currently answers two different questions: "may this person read the
documentation?" and "may this person change it for everybody?"

**This isn't theoretical.** Implementing the site-side workaround, my first pass lent `edit_posts`
to those AJAX endpoints as well as to the page render — which would have let any logged-in user
retag the documentation site-wide. Caught before it reached anyone, but it's exactly the mistake
the current shape invites: anyone bridging "let them read" naturally bridges the whole capability.

## 2. Filter or change the default? Filter

Keep the default at `edit_posts` and make it filterable. Reasoning:

- Changing a default **widens access on every installed client site at update time**, with nobody
  deciding it. That's the kind of change that should be opted into, not inherited.
- "Inert documentation" is nearly true, but guides do describe internal workflow, admin URLs and
  who-does-what. Not secret, but not obviously show-everyone either.
- The filter is reversible in the safe direction: a site that wants it open sets one line. If you
  later decide `read` is the right default, you can make that change deliberately, having watched
  it work somewhere first.

## What to build

Two filterable capabilities, both defaulting to `edit_posts` so nothing changes for anyone:

- **`bw_guides_read_capability`** — browse, search, open a guide.
- **`bw_guides_manage_capability`** — tags, notes, triggering a sync, settings, and the CPT
  authoring screens.

Point `BW_Guides_Ajax` at **manage**, not read. That's what makes "everyone can read" safe to turn on.

One UI consequence worth doing in the same change: a read-only viewer shouldn't be *shown* the tag
editor or the note field. Right now they'd render and then fail on save, which reads as a bug
rather than as a boundary.

## What happens on the Brentwood side when you ship

Nothing you need to coordinate. That site runs a shim — a capability borrow scoped to the guides
page render only, deliberately not covering the AJAX endpoints after the near-miss above. It
already detects whether the plugin exposes its own read capability, and when it does the borrow
stops being registered and the stand-in menu disappears by itself. So you can ship whenever
suits; nothing there needs changing in step with it.

For reference, the same shape on the Lead AI side is now done and live: `bw_lead_ai_view` /
`bw_lead_ai_manage`, filterable, floored to `manage_options` holders so no existing site loses a
screen. Worth a look as a precedent — particularly the detail that the floor applies only to the
**shipped** capability names, so a site that filters to a name of its own keeps control. Brentwood
uses exactly that to stop its IT team being able to purge lead data.