Critical: no accept-invitation mechanism — accepted_at gate from #131 permanently locks out all invited collaborators

Summary

Since the Sep 9 security/131-wire-write-authz merge (#131), every push from a non-owner collaborator returns 403 — including aaronrene's, on both gabriel/musehub and gabriel/muse. This is currently blocking all of aaronrene's work, including the fix for this exact ticket, since shipping it requires a push.

Root cause

accepted_at on collaborator rows gates all non-owner writes (per #131's fix). aaronrene's rows are admin, invited by gabriel — but accepted_at is NULL, and nothing in MuseHub can set it:

• No accept route (REST)
• No MCP tool
• No CLI verb
• invite_collaborator only writes invited_at, never accepted_at

So an invited collaborator has no way to ever transition to "accepted," and #131's new gate — correct in intent — permanently locks out every invited collaborator who was invited before an accept mechanism existed.

Immediate unblock

gabriel can set accepted_at directly via SQL on aaronrene's two collaborator rows (musehub, muse) to unblock him today while the real fix lands.

Real fix

Add an actual accept-invitation path — at minimum one of:

• POST /repos/{repo}/collaborators/accept (or similar) REST route
• muse hub collaborator accept <repo> CLI verb
• Corresponding MCP tool

Should set accepted_at = now() on the invited row, scoped to the authenticated identity matching the invited handle (an identity must not be able to accept someone else's invitation).

Related

• #131 — the write-authorization fix that introduced this gate without a corresponding accept mechanism.

Source

Reported by aaronrene, 2026-09-10 (relayed via message to gabriel, processed 2026-09-11). Original message: "Could you set accepted_at on my collaborator rows for gabriel/musehub and gabriel/muse? ... The invite can't be accepted, and I can't ship the fix for that either, because it needs a push. Details on #131."

Mirrored from staging#193.