Add artifact owners and an opt-in restricted access setting

[josipmrsic]

Hi! This is the follow-up we mentioned in #86. We run Artifact Server for our company (about 300 people), and one thing would help a lot: letting an author keep an artifact to themselves. Today every member can find, read, overwrite, and delete every artifact, and many pages people publish from their agents are drafts that aren't ready to share.

We know f1586f7 removed per-artifact ownership on purpose, so this is a draft. We built and tested it end to end, but the direction is yours to decide. Would you take an opt-in, per-artifact setting like this at all? If not, we'd rather hear it early.

The idea

• Every artifact records its owner, the principal that created it. Existing artifacts are backfilled from their version 1 publisher.
• A third access setting, restricted, joins account_required and public_link. Only the owner and installation administrators can see or manage the artifact.
• Nothing changes unless someone picks it. account_required stays the default.

The removed ownership only gated changes and never reading, so this is a new, narrow rule, not the old manage:owned / publish:owned pair coming back. Decision record 0030 has the reasoning and the rejected alternatives.

Who	restricted artifact
Owner (browser, MCP OAuth, or the owner's member-bound key)	everything, as today
Installation administrator	everything
Other members and service principals, even with artifact:manage:any	not listed or searchable; every request answers 404 ARTIFACT_NOT_FOUND, the same as for a missing artifact

Only the owner or an administrator can switch an artifact to or from restricted. The switch ends other people's open content sessions immediately.

Questions for you

1. Is the setting acceptable in principle?
2. Administrators see restricted artifacts, for pages that must come down and for owners who leave. Is that OK?
3. For storage, we used a flag beside access_setting rather than a third CHECK value, which would need a rebuild of artifacts on SQLite and D1. Do you have a preference?
4. Is renaming the share option "Private" to "Signed-in members" OK? It reads oddly next to "Only me".

If it's easier to review, we're happy to split this into (a) recording owners and (b) the restricted setting.

Behavior details

• Listings filter in SQL on all three backends, so pagination, counts, search, and sort-by-comments stay correct.
• The switch to restricted deletes other principals' content sessions and unconsumed bootstraps in the same transaction. Administrators simply open the artifact again.
• Only a person can publish a new restricted artifact, because a service principal would own something it could never see.
• Dispatch treats a thread of a restricted artifact the sender can't see like an unknown thread. Agents read threads through the normal comment operations, which apply the same visibility.
• In local-owner mode, MCP doesn't advertise the setting, since that mode has one person.
• There's no CLI --only-me flag yet; happy to add one.

Storage and migrations

artifacts gains a nullable owner_principal_id and a restricted flag. idempotency_records gains restricted for replays. access_setting and its CHECK stay untouched, and the repositories map the pair to one API field with three values.

Backend	Migration
SQLite	schema 13
D1	revision 10
Postgres	0012_artifact_owner

The Postgres migration creates its index before the backfill. The backfill queues events for the deferred artifacts_current_version_fk, and Postgres refuses CREATE INDEX on a table with pending trigger events. The populated-v1 upgrade test caught this.

Spec and tests

• Spec: decision 0030; AUTH-030 (owner) and AUTH-031 (restricted), both implementing with proof gaps; amended AUTH-002, AUTH-008, SCP-008-F, and product-spec wording.
• Conformance tests: tests/conformance/auth-030-031-artifact-owner-restricted.test.ts drives the local server with an administrator, member-bound keys, and a service key. It covers owners and the backfill, owners surviving other members' changes, full use by the owner and administrator, and outsiders refused like a missing artifact, including revocation and dispatch.
• Runtime tests: Postgres and D1 tests cover owners, the listing filter, replay, and the D1 upgrade backfill.

Verification

• pnpm check, the Postgres suite (19/19), and the browser suite (27/27) pass locally.
• The full gate passes on our fork, Linux and macOS: https://github.com/josipmrsic/artifact-server/actions/runs/37930691090. That branch adds only the RDS fix from Update the pinned Amazon RDS CA bundle checksum #87; the code is otherwise identical.
• We also tested by hand against Microsoft Entra ID with a second member.