Varlock Documentation Audit
Varlock's docs are broad, agent-conscious (llms.txt, llms-full.txt, llms-small.txt all published), and unusually candid about failure modes — but the reference and the guides contradict each other on a secret-path format, five integration pages share the same broken anchor link, and the docs repeatedly use decorators they themselves mark deprecated.
1. 1Password secret reference format contradicts the plugin reference (critical)
Location: /guides/secrets/ (Bulk injection section) vs /plugins/1password/
Problem: The 1Password plugin reference defines the canonical secret reference format as op://vault-name/item-name/field-name (vault → item → field), and its examples follow it: ITEM=op(op://vault-name/item-name/field-name). But the secrets guide's @setValuesBulk() example writes @setValuesBulk(op("op://vault/field/item")) — vault → field → item, with the last two segments swapped. The swapped string is present on the live rendered page, not just the text export.
Consequence: A developer (or an AI agent reading llms-full.txt, where both pages appear) who copies the guide's pattern will construct secret references with the item and field reversed. 1Password lookups will fail — or worse, silently resolve the wrong field if names happen to collide. Humans might notice the plugin page disagrees; an agent that landed on the secrets guide first will not, and contradictions like this make agents fail silently.
The fix: Correct the @setValuesBulk example to op("op://vault/item/field") and audit all op:// strings across the docs for consistent vault/item/field ordering.
2. Same broken anchor link on five integration pages (significant)
Location: /integrations/php/, /integrations/go/, /integrations/python/, /integrations/rust/, /integrations/other-languages/
Problem: All five non-JS language integration pages open with the same sentence linking to [install the standalone binary](/getting-started/installation/#as-a-binary). The installation page has no id="as-a-binary" anchor — its only section anchors are as-a-javascripttypescript-dependency and as-a-standalone-binary (verified against the rendered HTML; the live PHP page contains href="/getting-started/installation/#as-a-binary").
Consequence: Every developer arriving from a non-JS integration page — exactly the audience that must use the standalone binary — clicks through and lands at the top of the installation page, where the first thing they see is the JavaScript/TypeScript install path. The one link meant to route them to the right section silently drops them at the wrong one, on all five pages at once because the intro is templated.