Publish content visibility declaration Lexicon

[vineyardbovines]

Summary

• mirror app.bsky.actor.contentVisibilityDeclaration from Add content visibility lexicon atproto#5372
• publish the schema through the authoritative bsky Lexicon workflow
• retain the specified behavior that a missing preference record means hideFromAlgorithmicRecommendations: false

Context

The schema is already present in atproto, social-app, and indigo, and shipped in @atproto/api, but was not mirrored to this publishing repository. As a result, network Lexicon resolution currently fails with invalid lexicon record proof.

Test plan

• verified the JSON parses successfully
• verified the file exactly matches the social-app schema
• verified git diff --check passes

[claude]

Claude finished @vineyardbovines's task in 4m 8s —— View job

---

Review: Publish content visibility declaration Lexicon

• Read .github/claude-review-prompt.md and repo conventions
• Inspect the added lexicon against sibling actor records
• Trace the publishing pipeline and SDK codegen path
• Assess whether a changeset / SDK update is required

---

The change looks fine and is scoped correctly. contentVisibilityDeclaration.json is well-formed and matches the shape of its neighbors (key: "literal:self", type: record, record-level description), and app.bsky.actor is a non-carveout group that resolves to the authoritative publishing DID, so it will flow through lexicons-publish.yml / goat as intended.

What I checked and why it's not a finding:

• No changeset needed. The published @bsky/sdk lexicons are not generated from this repo's root lexicons/. They're produced by packages/sdk/scripts/install-lexicons-local.mjs, which copies from an external atproto checkout (packages/sdk/lexicons/ + lexicons.json). So adding a root lexicon here doesn't alter any published package export, and the review-prompt's "public export = semver event" rule doesn't apply to this PR.
• DNS/carveout audit passes. Only app.bsky.unspecced is carved out (.github/lexicons.json); app.bsky.actor is expected to publish.

One high-impact thing worth a final check (non-blocking, uncertainty flagged):

The entire goal here is to make network resolution stop returning invalid lexicon record proof. That proof is a CID computed over the canonical (DAG-CBOR) form of the lexicon content — so it hinges on this JSON being structurally identical to the version baked into @atproto/api / indigo / social-app, not just visually similar. A single differing character in the description string, or a different required/key value, produces a different CID and the proof would still fail for every consumer after publish.

The PR body says this was verified against the social-app schema, which is the right check — I just can't independently confirm it from here (no network access in this run). Since the cost of a mismatch is "the fix doesn't actually fix anything," it's worth one explicit CID/byte-equality confirmation against the canonical atproto source before merge rather than a visual diff. The description text is the most likely place for a silent drift.

Nothing else stands out.
· branch publish-content-visibility-lexicon