There is a real code smell/bug candidate:

• frontend/apps/desktop/src/models/documents.ts computes visibility = ResourceVisibility.PRIVATE for a first publish of a private draft.

• But if the publish goes through the daemon path, frontend/apps/desktop/src/utils/publish-document.ts rewrites it to:

visibility: ResourceVisibility.UNSPECIFIED

in createDocumentChangeRequest(...).

So the daemon request drops the caller’s visibility intent.

On the backend:

• backend/api/documents/v3alpha/documents.go

treats visibility like this:

• PRIVATE → make ref private

• PUBLIC → make ref public

• UNSPECIFIED → keep existing visibility for updates, default to public for new docs

So if a new private document were published through the daemon path with UNSPECIFIED, it could become public.

This is probably not the main explanation for “first publish of a private document doesn’t behave private.”

Why:

Likely only narrower cases:

1. Updates / re-publishes of existing docs that use daemon

2. Home/root docs, which also use daemon

But:

• updates with UNSPECIFIED keep existing visibility on the server, so that is often harmless

• root docs cannot be private anyway (documents.go rejects private root docs)

So the daemon bug looks real, but also lower impact than it first appears.

There are signs the team already suspected a visibility issue:

• frontend/apps/desktop/src/models/documents.ts has:

  • // TODO(temp): remove after verifying private document visibility fix

  • logging of requestedVisibility and returnedVisibility

Also, the current unit test codifies the problematic behavior:

• frontend/apps/desktop/src/utils/__tests__/publish-document.test.ts

expects createDocumentChangeRequest(...PRIVATE...) to still produce:

ResourceVisibility.UNSPECIFIED

So the bad behavior is currently baked into tests.

• you are testing as the owner, who is allowed to see private docs

• UI surfaces intentionally include private docs for writers

  • useCanSeePrivateDocs(...) returns true for writer capability on the site home

• the environment you tested may not be enforcing PublicOnly

• or there is a separate privacy bug elsewhere

The daemon-path visibility bug is real, but probably not the primary cause of “private docs don’t behave private on first publish.”

The desktop daemon publish path drops requested private visibility by forcing ResourceVisibility.UNSPECIFIED in frontend/apps/desktop/src/utils/publish-document.ts, and the backend treats unspecified as “preserve on updates, default public for new docs.” However, first publish of non-home private docs usually bypasses daemon and uses the generic client signing path, which correctly preserves "Private" visibility in the Ref blob.

• The daemon issue is real and currently even reflected in tests.

• It is probably lower-impact than it first looks because the affected daemon flows are mainly updates and root docs.

• Your observed “not private” behavior is more likely due to owner/writer access, environment config (PublicOnly), or another privacy bug outside this daemon path.