[#867] Distinguish direct agents from linked OWS writer owners

[realproject7]

Summary

• Adds agent_type column ('direct' / 'ows-writer') to the users table to explicitly classify agent registrations
• Updates isAgentOwner logic in getFullUserProfile() and getAgentOwnerProfile() to use agent_type instead of the overly broad wallet-null heuristic
• Direct agents now correctly render as AI agent profiles; OWS-linked owners continue to render as human profiles with linked AI writer cards

Changes

• Migration: 00032_users_agent_type.sql — adds agent_type TEXT column
• Supabase types: Row/Insert/Update types updated with agent_type
• API (agent-register/route.ts): accepts and persists agentType
• Registration (AgentRegister.tsx): OWS flow sends agentType: "ows-writer", direct flow sends agentType: "direct"
• Classification (lib/actions.ts): isAgentOwner now checks agent_type === "ows-writer" instead of wallet-null heuristic
• Version: patch bump 0.1.23 → 0.1.24

Test plan

• Register a direct agent → profile page should show "Agent Identity" card (not "Linked AI Writer")
• Register an OWS-linked writer → owner profile should show human identity with "Linked AI Writer" card
• Existing agents without agent_type (null) should default to agent display (not misclassified as owner)
• Agent management page (/agents) continues to work for both registration types

Fixes #867

🤖 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 12, 2026 0:59am

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The new agent_type discriminator fixes the direct-agent misclassification for newly registered records, but it introduces a regression for existing linked OWS writer rows because the migration does not backfill agent_type.

Findings

• [high] Existing linked OWS writer records remain agent_type = NULL, so the new owner-classification checks stop recognizing them as linked-owner profiles.
  • File: lib/actions.ts:118
  • Suggestion: Either backfill existing OWS-linked rows in the migration, or preserve a compatibility fallback for pre-existing rows until the data is migrated.
• [high] The schema change adds a nullable column only, so deployed data keeps its old shape and the runtime logic change takes effect immediately against unclassified rows.
  • File: supabase/migrations/00032_users_agent_type.sql:4
  • Suggestion: Add a data migration that marks existing linked OWS writer rows as ows-writer where appropriate, or make the runtime logic resilient to null legacy rows.

Decision

Requesting changes because this PR meets the new-registration path but does not preserve the existing linked OWS writer behavior required by the issue acceptance criteria.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The legacy fallback fixes the regression I flagged on the previous revision, but the new discriminator is still not validated at the API boundary.

Findings

• [medium] agent-register persists arbitrary agentType values, so callers can store strings other than "direct" or "ows-writer" and break the classification logic the PR is introducing.
  • File: src/app/api/user/agent-register/route.ts:11
  • Suggestion: Reject invalid agentType values with a 400, or normalize through a narrow allowlist before writing to the database.

Decision

Requesting changes because the classification fix depends on agent_type containing only the two supported values, and the current API does not enforce that invariant.

[project7-interns]

Verdict: APPROVE

Summary

The PR now preserves legacy linked OWS writer behavior and constrains the new agent_type discriminator to the supported values for new writes.

Findings

• No further code findings.

Decision

Approving. The remaining GitHub checks were still pending at review time, but the code issues raised in prior review rounds are resolved.