docs: correct the duplicate-w:id guidance and sync docs/api.md

The per-id caveat advised falling back to the row's group_id, which is exactly
what a duplicated id does not have: _reconstruct_groups bars every occurrence
from grouping, as this PR's own TestGroupResolutionWithDuplicateIds asserts.
Two rows sharing an id in list_revisions() is the signal instead, and the
author-filtered bulk calls are the way to resolve them.

docs/api.md carried neither the author-scoping guarantee nor the per-id
caveat; its accept_all/reject_all/accept_revision/reject_revision sections now
match SKILL.md, as every prior change to this prose has kept them.

ROADMAP #75 no longer describes the fixed behaviour as current, and records
why the w:id index was scoped by author instead of the filed element-identity
suggestion. #83's fix direction named _reconstruct_groups as the sole writer
of an explicit None group; _adopt_split_tail also writes one for an
unambiguous split tail, so it points at the duplicate_ids set instead.

has_own_revisions says why it keeps the raw w:author rather than
_revision_author: an editor named "Unknown" must not claim unattributed marks.

Author: pablospe

ROADMAP.md

@@ -59,7 +59,7 @@ Only `w:instrText` is known to the library today. A `replace()` targeting text i
 
 ### 75. Author-filtered bulk resolution must not touch other authors' revisions  [data loss; after #73 step 9]
 
-`accept_all(author=A)` / `reject_all(author=A)` list revisions by author but resolve by `w:id`, and the id lookup has no author check. With B's `<w:ins w:id="7">` before A's `<w:del w:id="7">` (duplicate ids across authors occur in real files — the corpus has them from LibreOffice), `reject_all(author="A")` deletes B's inserted text and `accept_all(author="A")` makes it permanent, both reporting 2. The `accept_all` docstring documents this and `tests/test_track_changes.py::…:1143` pins it as expected — it is not acceptable for a data-loss path. Fix: resolve the exact elements selected by the listing (element identity), not their ids; flip the pinning test. Lives in the resolution cluster, so it lands after #73 moves it (found by CodeRabbit on PR #75; verified 2026-08-30).
+`accept_all(author=A)` / `reject_all(author=A)` list revisions by author but resolve by `w:id`, and the id lookup has no author check. With B's `<w:ins w:id="7">` before A's `<w:del w:id="7">` (duplicate ids across authors occur in real files — the corpus has them from LibreOffice), `reject_all(author="A")` deletes B's inserted text and `accept_all(author="A")` makes it permanent, both reporting 2. The `accept_all` docstring documented this and a test pinned it as expected — not acceptable for a data-loss path (found by CodeRabbit on PR #75; verified 2026-08-30). **Fixed in PR #96**, by scoping the w:id index to the author being resolved rather than the filed suggestion of resolving element identities: `Revision` carries no element handle, so identity would have meant a wider signature change for the same outcome — a same-id element of the *same* author still resolves in one pass either way. The pinning test is flipped. The per-id verbs keep the defect; that is #83.
 
 ### 79. Inserted text loses formatting after an empty split segment  [after #73 step 7]
 
@@ -75,7 +75,7 @@ The #91 diagnostics caught it on their first CI failure (run 33331432527, load a
 
 ### 83. `accept_revision`/`reject_revision` resolve a duplicated `w:id` by position  [data loss]
 
-The per-id half of #75, which fixed only `accept_all`/`reject_all`. With B's `<w:ins w:id="7">` before A's `<w:del w:id="7">`, `list_revisions(author="A")` returns one row with id 7, and `reject_revision(7)` deletes B's inserted text and leaves A's deletion pending; `accept_revision(7)` makes B's insertion permanent. The caller cannot disambiguate — `Revision` carries no element handle — and `SKILL.md` documents this exact per-id pattern. Fix: either give the per-id verbs an author/identity selector, or refuse an ambiguous id with a teaching error; the manager already knows which ids are ambiguous, since `_reconstruct_groups` is the sole writer of `self._revision_groups[rev_id] = None` (`registry.py`) and writes it only for duplicated ids. SKILL.md carries an interim caveat. Found by the multi-review of PR #96.
+The per-id half of #75, which fixed only `accept_all`/`reject_all`. With B's `<w:ins w:id="7">` before A's `<w:del w:id="7">`, `list_revisions(author="A")` returns one row with id 7, and `reject_revision(7)` deletes B's inserted text and leaves A's deletion pending; `accept_revision(7)` makes B's insertion permanent. The caller cannot disambiguate — `Revision` carries no element handle — and `SKILL.md` documents this exact per-id pattern. Fix: either give the per-id verbs an author/identity selector, or refuse an ambiguous id with a teaching error. The duplicate set is already computed — `duplicate_ids` in `_reconstruct_groups` (`registry.py`) — and then discarded; retain or recompute it rather than testing `_revision_groups[id] is None`, which `_adopt_split_tail` also writes for an unambiguous split tail whose origin was ungroupable. SKILL.md carries an interim caveat. Found by the multi-review of PR #96.
 
 ### 84. `_rejoin_paragraph` drops the tail paragraph's other revisions  [data loss]
 

docs/api.md

@@ -867,6 +867,14 @@ accepting the `move_to` and rejecting the `move_from` duplicates the text, the
 inverse loses it. A lone half in a damaged file behaves as what it structurally
 is: a `move_from` alone is a deletion, a `move_to` alone an insertion.
 
+**Duplicate ids are ambiguous here.** A producer may reuse one `w:id` across
+authors, and this call takes only the id: handed a duplicated one it resolves
+whichever element comes first in the document, which may be another author's.
+Groups are no way around it — a duplicated id is barred from grouping, so both
+rows carry `group_id=None`. Two rows sharing an id in `list_revisions()` is the
+signal; resolve them with `accept_all(author=…)`/`reject_all(author=…)`, which
+is author-exact.
+
 **Parameters:**
 
 - `revision_id` (int): ID of the revision to accept
@@ -892,7 +900,8 @@ Reject a revision by ID.
 - For `property_change`: restores the paragraph's recorded previous properties. A record with none (LibreOffice writes a self-closing `w:pPrChange` for "previously no properties") clears them; the recorded style id is restored verbatim even when the document defines no such style (Word falls back to Normal for it)
 - Nested revisions: rejecting an insertion removes everything inside it — deletions another author nested inside it disappear with it
 
-Resolve both halves of a move together — see `accept_revision()`.
+Resolve both halves of a move together — see `accept_revision()`, whose
+duplicate-`w:id` caveat applies here too.
 
 **Parameters:**
 
@@ -1080,6 +1089,11 @@ marker is dropped without merging or splitting paragraphs.
 Only `word/document.xml` is inspected; headers, footers and footnotes are the
 container-parts epic (ROADMAP.md #30).
 
+An `author=` call resolves that author's own elements and no one else's, even
+where a producer repeats one `w:id` across authors (LibreOffice does): the id
+lookup is scoped to the author being resolved, so another author's same-id
+revision is never a candidate.
+
 **Parameters:**
 
 - `author` (str, optional): If provided, only accept revisions by this author
@@ -1109,7 +1123,8 @@ Reject every listed revision.
 Resolves insertions, deletions, content moves (both halves as a unit — the
 text is back at its source exactly once) and paragraph-property changes (the
 recorded previous properties are restored); every other revision type is left
-pending and reported exactly as in `accept_all()`.
+pending and reported exactly as in `accept_all()`. `author=` is author-exact in
+the same way, duplicate `w:id`s across authors included.
 
 **Parameters:**
 

skills/docx/SKILL.md

@@ -682,8 +682,10 @@ nested deletion's `nested_under` points back at its host.
   reuse one `w:id` across authors, and `accept_revision(id)`/
   `reject_revision(id)` take only the id: handed a duplicated one they resolve
   whichever element comes first in the document, which may be the other
-  author's. When a listed revision shares its id with a second row, prefer
-  `accept_all(author=…)` / the row's `group_id`.
+  author's. Groups are no way around it — a duplicated id is barred from
+  grouping, so both rows carry `group_id=None`. Two rows sharing an id in
+  `list_revisions()` is the signal; resolve them with
+  `accept_all(author=…)`/`reject_all(author=…)`, which is author-exact.
 
 **Moves are two rows.** A drag-and-drop move lists as a `move_from` (the
 source, text excluded from the visible view) and a `move_to` (the