[#993] Redesign Link AI Writer flow: fetch tokenURI first, pre-fill agent data

[realproject7]

Summary

Fixes #993

• New GET /api/user/lookup-agent endpoint: fetches agent data via balanceOf → tokenOfOwnerByIndex → tokenURI RPC calls; supports manual agent ID fallback when enumeration isn't available
• Simplified POST /api/user/link-agent: accepts pre-fetched agent metadata from frontend (no RPC calls during linking), stores agent_id/name/description/genre in DB
• Redesigned LinkAIWriter component: multi-step flow — enter OWS wallet → click Lookup → view agent info card → paste binding signature → link
• Fixed erc8004.ts: added tokenURI to ABI, getAgentMetadata/getAgentMetadataById now try tokenURI first (falls back to agentURI)
• Version bump 1.0.2 → 1.1.0

Test plan

• Enter OWS wallet address + click Lookup → agent info card displays
• Agent ID is pre-filled from lookup (user doesn't type it)
• When tokenOfOwnerByIndex fails, manual agent ID input appears
• Only binding signature needs manual paste after lookup
• Profile shows correct agent name after linking
• Direct registration flow remains unchanged
• Build passes (npm run build)

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Apr 24, 2026 6:39am

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The lookup-first UX is headed in the right direction, but the server now trusts client-supplied agent metadata during linking and it still drops part of the tokenURI payload that the issue requires us to persist.

Findings

• [high] POST /api/user/link-agent writes agentId / agentName / agentDescription / agentGenre straight from the request body into the OWS user row after only verifying the wallet signatures. A caller can bypass the lookup endpoint and submit arbitrary metadata for any OWS wallet they control, which poisons the cached agent record and breaks the intended server-side ownership guarantee.
  • File: src/app/api/user/link-agent/route.ts:129
  • Suggestion: Do not trust these fields from the client. Re-derive the canonical agent data server-side, or have the lookup endpoint mint a server-verifiable payload/signature that the link endpoint verifies before writing metadata.
• [medium] The new flow still does not persist the full tokenURI data required by the issue. lookup-agent returns llmModel and registeredAt, but LinkAIWriter never sends them and link-agent never stores them, so OWS rows remain inconsistent with direct registration and the "ALL agent data from tokenURI" requirement is not met.
  • File: src/components/AgentRegister.tsx:133
  • Suggestion: Include the missing metadata fields in the POST body and persist them to the corresponding DB columns (agent_llm_model, agent_registered_at).

Decision

Requesting changes because the current link route crosses a trust boundary incorrectly and the stored agent record is still incomplete relative to the issue requirements.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The server-side trust boundary is fixed, but the link route still fails open: it can return success even when the supplied agentId cannot be verified or its metadata cannot be fetched, which leaves the OWS row incomplete while the user sees a successful link.

Findings

• [medium] POST /api/user/link-agent catches all RPC/metadata lookup failures and still returns { ok: true }. Because the frontend now always sends agentId from the lookup step, a failure here means the link completes without agent_id / agent_name / agent_description / agent_genre / agent_llm_model / agent_registered_at, violating the issue requirement that the DB be populated from tokenURI and making the success state misleading.
  • File: src/app/api/user/link-agent/route.ts:141
  • Suggestion: When agentId is present, fail the request if ownerOf(agentId) does not match owsWallet or if canonical metadata cannot be resolved. Only succeed once the verified metadata has been written.

Decision

Requesting changes because the route still allows a false-success path that skips the required metadata persistence.

[project7-interns]

Verdict: APPROVE

Summary

The link flow now verifies canonical agent ownership/metadata server-side and fails closed when that verification cannot be completed. The lookup-first UX and metadata persistence match the issue requirements.

Findings

• None.

Decision

Approving. The previous trust-boundary and false-success issues are addressed. Note that e2e and lint-and-typecheck were still pending at the time of review.