Fix Invite Page Avatar and Metadata IssuesPublic

Using the git-worktree skill because this is a worktree setup request. I’m checking the local workflow instructions first, then I’ll create the worktree on a codex/-prefixed branch if needed and verify the result.

The repo’s worktree script is the right path here. I’m checking whether a matching worktree or branch already exists, then I’ll create a new worktree from the current main HEAD using a codex/feat-namespace-invite-opengraph branch.

I’ve confirmed there isn’t an existing branch or worktree with that name. Creating a fresh worktree now under the standard traces-worktrees/ directory and letting the script handle env symlinks and dependency install.

The worktree itself is in place; bun install is still finishing inside it. I’m waiting for that to complete, then I’ll verify the new path and branch state.

I used the git-worktree skill from this repo, but I’m checking whether there’s another custom worktree skill or script you intended before changing anything else.

There isn’t a separate workftree or other custom worktree skill in this repo. The only matching local skill is /Users/maxgeorgopoulos/Documents/traces/.agents/skills/git-worktree/SKILL.md, and that’s what I used.

The worktree is already created at /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph on branch codex/feat-namespace-invite-opengraph. If you meant a different branch name or a different custom script, point me at it and I’ll adjust.

Yes. The worktree exists at /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph on branch codex/feat-namespace-invite-opengraph, with env symlinks and dependencies installed.

I’ll switch my work context to that worktree and verify the directory before doing anything there.

Working from /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph now.

I’m tracing invite data from the backend/types up to the linked page so we know exactly what fields are available for an Open Graph image. I’ll inspect the repo instructions for the relevant packages, then locate the namespace invite flow and page components.

I’ve located the invite flow. Next I’m reading the package-specific instructions plus the shared type, backend service, and the /invite/[code] page so we can map available backend fields to what the linked page already exposes.

The public invite API is richer than the current invite page UI. I’m confirming the exact response contract now, because a couple of fields already exist in the backend but are not rendered on the page, and one status case on the page looks stale.

The public contract confirms a few useful OG candidates: namespace description, type, avatar, role, expiry, and usage limits. I’m checking the namespace schema next so we can separate what’s actually available today from what would require a new backend field.

I have enough to outline the available invite data. I’m doing one last check for route-level metadata or an existing OG image implementation on the invite path so we know whether this will be a new server-side entry point or an update to an existing one.

There’s no invite-specific metadata or image route today. I’m reading the existing opengraph-image pattern used elsewhere in the app so the eventual invite implementation can match the existing approach instead of inventing a parallel one.

I’m also checking how invites are created, because that tells us whether the public image needs to support more than one role, targeted email invites, or multi-use variants.

I’ve got the functional picture. I’m grabbing precise line references for the backend contract and the page so I can hand you a clean inventory of what’s displayable now, what the current page already shows, and what would need an API change.

I checked the actual linked route at /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/frontend/app/(main)/invite/[code]/page.tsx#L24 and traced its data source back to the public invite lookup in /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/api/convex/services/invites.ts#L141.

What we can display today from the public invite lookup

• Namespace displayName, slug, description, type, and avatarUrl come back from GET /v1/invites/:code in invites.ts:153.
• Invite role, status, expiresAt, maxUses, and useCount also come back there in invites.ts:164.
• Invites currently always create with role "member" and expire after 7 days, from internal/invites.ts:36 and packages/shared/src/invite.ts:42.
• Multi-use state is already available: unlimited (maxUses = 0), capped, and current usage count. The admin UI already exposes that model in InviteManager.tsx:25 and InviteManager.tsx:162.

What the current invite page already shows

• Avatar, namespace name, @slug, role, expiry countdown, and login/join CTA are rendered in page.tsx:246.
• Expired and revoked states have dedicated views in page.tsx:164 and page.tsx:190.
• The page does not currently render namespace description, namespace type, maxUses, or useCount, even though the API returns them. Its local InviteDetail type omits those fields in page.tsx:12.

Important constraint / bug for OG design

• The shared status type includes accepted, but getInviteStatus() only returns pending, revoked, expired, or fully_used in invite.ts:54.
• The current page checks for invite.status === "accepted" in page.tsx:215, but public lookup tests expect exhausted invites to come back as fully_used in invites.test.ts:1085. So the page has a stale status branch and no explicit fully_used UI.

What we do not have publicly without an API change

• invitedBy, email, createdAt, acceptedAt, and acceptedBy exist on the invite model/admin responses in packages/shared/src/invite.ts:11 and api/convex/services/invites.ts:43, but the public lookup does not return them in api/convex/services/invites.ts:153.

There’s also no invite-specific generateMetadata or opengraph-image route yet; the app only has that pattern for the homepage and trace pages. If you want, I can make the next pass about what the OG image should include from this data and where to implement it.

Using the next-best-practices skill here because this is an App Router metadata/image route change. I’m checking the invite route structure and existing OG conventions, then I’ll add invite-specific metadata and an opengraph-image that uses the public invite data without showing expiry.

The invite route only has a client page today, so I’m adding the missing server-side pieces: a route-level layout.tsx for metadata and a sibling opengraph-image.tsx. I’m reusing the existing OG tokens/components so the new image matches the rest of the app rather than introducing a one-off style.

I’ve got the shape of the change. I’m adding a small shared invite-fetch helper for server metadata/image generation, then wiring in a new layout.tsx and opengraph-image.tsx under /invite/[code] so the page gets the requested title/description and a dedicated OG image with avatar plus invite copy only.

I’m editing the invite route now. The change set is limited to new server-side metadata/image files for /invite/[code], plus a small shared fetch helper so the title/description/image all stay in sync.

The server-side pieces are in place. I’m running a quick frontend lint pass against the new invite metadata/image files now to catch any App Router or JSX issues before we stop.

Lint is still running. Once it returns, I’ll do a quick diff review to make sure the invite image and metadata text match exactly what you asked for and that no expiry copy slipped in.

The repo-wide lint run has pre-existing failures in generated .source/* files, but it also surfaced one harmless warning in the new OG file. I’m cleaning that up, then I’ll run eslint only on the files I added so we have a clean check for this change.

The repo-wide lint noise is out of the way. I’m just waiting on a targeted eslint pass for the three new invite files so we can verify this change independently of the existing generated-file issues.

The invite metadata files lint clean now. I’m doing a final diff review and checking the exact text in the new metadata/image paths before I hand it back.

The added files lint clean. I’m running a typecheck from frontend/ as one more guard because the new route code is all server-side App Router code and I want to catch any typing issues there before we stop.

Typecheck is still running. If it comes back clean, this change is ready; if it fails, I’ll separate any repo-level noise from anything caused by the new invite OG route.

Added invite-specific metadata and an OG image for /invite/[code]. The new layout.tsx sets the page title to You've been invited to join [orgname] and the description to Join [Org] to start sharing agent traces. The new opengraph-image.tsx renders the namespace avatar, the invite title, and that short description, with no expiry copy. I also added invite-metadata.ts so the metadata and image both read from the same public invite lookup.

Verification: targeted eslint passed for the three new files, and bun run typecheck passed in /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/frontend. A repo-wide bun run lint still reports pre-existing errors in generated .source/* files, unrelated to this change.

I’m checking the current branch and worktree state first so I can pull main into this worktree safely, then I’ll run the update in place.

This worktree is on codex/feat-namespace-invite-opengraph with only the three new untracked invite files. I’m pulling origin/main into this branch now; if sandbox network blocks it, I’ll immediately retry with an approval request.

The pull fast-forwarded cleanly. I’m verifying the branch state after the update so I can confirm whether anything in this worktree needs follow-up.

Pulled origin/main into /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph successfully. It fast-forwarded to d774c4ca.

Main brought in updates to /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/frontend/components/Navbar.tsx, /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/frontend/components/VisibilityStatusBadge.tsx, and /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph/frontend/content/docs/cli/supported-agents.mdx. Your three new invite OG files are still untracked.

cd /Users/maxgeorgopoulos/Documents/traces-worktrees/codex-feat-namespace-invite-opengraph

I’m reproducing the invite OG route locally and checking the server-side fetch path it depends on. First step is to hit the route directly and inspect the current frontend env/config in this worktree.

The route is returning a straight 404 from Next, which means this isn’t an invite-data issue yet; the metadata route itself is not currently registered in the running app. I’m checking whether the local .next output knows about the new route, which will tell us if this is just a stale dev server that needs a restart.

The dev build does know about the invite metadata file, so the 404 is likely coming from Next’s file-based metadata routing rather than from our code. I’m checking the actual <meta> tags on the invite page to see what URL Next generated for the OG image instead of guessing the path format.