Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/config/wordlist.txt:
- Around line 24-25: The wordlist contains a duplicated entry "Testcontainers";
remove the second occurrence so each entry is unique (i.e., delete the repeated
"Testcontainers" line), and optionally run a quick dedupe check on the file to
ensure no other duplicates remain.
- Around line 686-687: Remove the duplicate entry "structs" from the wordlist:
locate the consecutive lines containing the token "structs" (the duplicate
entries shown in the diff) and delete one of them so "structs" only appears once
in .github/config/wordlist.txt.

In `@docs/adr/0017_typed_credentials.md`:
- Line 157: Replace the word "builtin" with the hyphenated form "built-in"
across the document where used; specifically update the sentence containing the
example "`com.hashicorp.vault.VaultCredentials/v1`" and the nearby phrase that
mentions "HelmHTTPCredentials/v1" (and the other occurrences that read "builtin
types" or "Builtin types") so they read "built-in types" or "Built-in types" as
appropriate for sentence case consistency; ensure you only change the
spelling/casing and keep the surrounding examples and punctuation intact.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docs/adr/0017_typed_credentials.md`:
- Around line 263-267: Reword the three consecutive sentences that start with
"Phase" (the lines describing Phase 2, Phase 4, and Phase 6) to improve flow and
readability—e.g., vary sentence openings and/or combine related ideas so the
text reads: explain that Phase 2 PRs can run in parallel across bindings, note
that Phase 4 waits for Phase 2 to complete, and emphasize that only Phase 6
removes backward compatibility while confirming old `.ocmconfig` files remain
compatible at every stage; update the paragraph containing these Phase
statements accordingly.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/adr/0017_typed_credentials.md`:
- Around line 174-175: Update the second bullet that currently reads "Built-ins
register first (at startup), plugins register after (at discovery) — built-ins
always take precedence" to reflect the duplicate-registration behavior: change
it to "Built-ins register first; conflicting later registrations error out" (and
keep the following bullet about nil-safe schemes as-is); ensure the edited text
matches the duplicate-registration policy described earlier so there is no
implication of runtime precedence.
- Around line 67-69: Update the ADR text in docs/adr/0017_typed_credentials.md
to remove ambiguity: state that credential/identity type mismatches are detected
at configuration/ingestion time and treated as an ingestion error (not just a
warning), or alternatively add a clear subsection that defines two modes
("strict" = fail at ingestion, "lenient" = warn and defer rejection to
consumers) and explicitly document the default behavior; reference the existing
sentence "The graph validates during ingestion that configured credential types
are compatible with the identity type" and change its wording to reflect the
chosen error behavior or add the strict/lenient mode description and default.
- Around line 76-77: Update the sentence about interface-breaking risk to avoid
absolutes: change the wording to say that adding a method to an interface breaks
implementors, note that while current implementations of credentials.Resolver
are in-repo, external projects or plugins could also implement it and would be
affected, and state that each binding migrates from Resolve to ResolveTyped
independently with plugin interfaces updated in Phase 3; modify the line
referencing "only breaks implementors (all in our codebase)" to this revised
phrasing mentioning credentials.Resolver, Resolve, ResolveTyped, and Phase 3.

---

Nitpick comments:
In `@docs/adr/0017_typed_credentials.md`:
- Around line 249-253: The repeated "Phase ..." sentence starts make the bullets
rote; update one bullet for variety—e.g., change "Phase 2 PRs can run in
parallel across bindings." to "PRs for Phase 2 can run in parallel across
bindings." or "Phase 2 allows PRs to run in parallel across bindings." Apply
this small wording change in the bullets block so only one line start is varied
while preserving meaning.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@docs/adr/0017_typed_credentials.md`:
- Around line 76-78: The sentence claiming that adding a method "breaks
implementors (all in our codebase)" is too absolute; update the text around the
discussion of changing the exported interface (the Resolve -> ResolveTyped
migration) to soften the claim and acknowledge that while current in-repo
implementors will be affected, external implementors could be impacted as well.
Rephrase to something like: adding a method will require each binding to migrate
from Resolve to ResolveTyped independently and may break existing implementors
within our codebase and any external implementations; ensure the wording
references the Resolve and ResolveTyped symbols and clarifies the scope of
impact without asserting "all" implementors unconditionally.
- Around line 67-69: The ADR text is ambiguous: the sentence "The graph
validates during ingestion that configured credential types are compatible with
the identity type." conflicts with "Incompatible pairs produce warnings." —
update the document so ingestion-time mismatches are treated as errors (not
warnings) or explicitly define strict/lenient modes and a default; specifically
change the behavior described around the two sentences ("The graph validates
during ingestion..." and "Incompatible pairs produce warnings.") to state either
(a) ingestion validation fails with clear errors for incompatible
credential/identity pairs, or (b) add a short section that defines a
configurable mode (strict vs lenient), document the default mode, and describe
that strict emits errors at ingestion while lenient emits warnings and defers
rejection to consumers.
- Around line 222-223: Update the wording to remove ambiguity about precedence
vs duplicate-registration behavior: state that built-ins register first and that
later conflicting registrations (e.g., plugin registrations) will fail fast
rather than override built-ins; mention that the system is nil-safe and falls
back to DirectCredentials when no scheme is provided. Reference the terms
"built-ins", "plugins", "DirectCredentials", and "duplicate registration" so
maintainers know which behavior and documentation lines to update.

---

Nitpick comments:
In `@docs/adr/0017_typed_credentials.md`:
- Around line 298-302: The three constraint bullets that begin with “Phase …”
are repetitive; edit one or two of them (specifically the lines containing
“Phase 2 PRs can run in parallel across bindings”, “Phase 4 blocks on Phase 2
completion”, and “Phase 6 is the only step that removes backward compatibility”)
to vary the phrasing for readability—e.g., convert one to a leading clause (“PRs
in Phase 2 can run in parallel across bindings”) or to a descriptive form
(“Phase 4: waits for Phase 2 to complete”) so the bullets scan more clearly
while preserving the original meaning.