Fix lib agreements

[SudiptaPaul-31]

Migrate Agreements from Supabase to Backend Client

Summary

Migrated agreements data access layer from direct Supabase queries to a new backend HTTP client. This establishes a centralized agreements backend client pattern and removes direct database access from the frontend services.

closes Thalos-Infrastructure/ThalosFrontend#102

Type of Change

• New feature
• Breaking change (refactoring for architecture improvement)
• Bug fix
• Documentation update

Changes Made

New Files

• src/agreements/agreements-backend.client.ts - New backend client for agreements API
  • Maps all agreement operations to HTTP endpoints
  • Implements typed request/response interfaces
  • Sends X-Wallet-Address header for backend validation

Modified Files

• src/agreements/agreements.module.ts

  • Added ApiClientModule import
  • Added AgreementsBackendClient provider and export

• src/agreements/agreements.service.ts

  • Replaced all direct Supabase queries with AgreementsBackendClient calls
  • Migrated methods: create(), getAgreement(), listByWallet(), updateStatus(), updateMilestone(), getActivity(), getByContractId(), linkContract()
  • Refactored assertCanAccessAgreement() to use backend client
  • Refactored logActivity() to use backend client
  • Preserved all public method signatures for backward compatibility

• src/disputes/disputes.service.ts

  • Added AgreementsBackendClient dependency
  • Updated openDispute() to use backend client for agreement status updates
  • Updated resolveDispute() to use backend client for agreement status updates
  • Updated cancelDispute() to use backend client for agreement status updates
  • Refactored logActivity() to use backend client
  • Refactored assertCanAccessAgreement() to use backend client
  • Preserved signatures for updateAgreementStatus() and logAgreementActivity() patterns

Endpoint Mappings

The new AgreementsBackendClient maps to the following backend endpoints:

Operation	Endpoint	Method
Create agreement	POST /agreements	createAgreement()
List by wallet	GET /agreements?wallet=	listAgreementsByWallet()
Get by ID	GET /agreements/:id	getAgreement()
Get by contract ID	GET /agreements/by-contract/:contractId	getAgreementByContractId()
Update status	PATCH /agreements/:id/status	updateAgreementStatus()
Update milestone	PATCH /agreements/:id/milestones	updateMilestone()
Get activity log	GET /agreements/:id/activity	getAgreementActivity()
Log activity	POST /agreements/:id/activity	logActivity()
Link contract	PATCH /agreements/:id/link-contract	linkContract()

Technical Details

Backend Client Features

• ✅ Typed request/response interfaces for type safety
• ✅ X-Wallet-Address header validation for authorization
• ✅ Error handling and logging
• ✅ Timeout support (default 30s)

Authorization Pattern

• Wallet validation moved to backend (via X-Wallet-Address header)
• Access control checks now validated by backend endpoints
• assertCanAccessAgreement() uses backend client for validation
• Disputes service maintains authorization checks through backend

Backward Compatibility

• ✅ All public method signatures preserved
• ✅ No breaking changes to AgreementsService API
• ✅ No breaking changes to DisputesService API
• ✅ Event emitters unchanged
• ✅ Error handling patterns consistent

Testing

Build & Lint

• ✅ npm run build - PASSED (exit code 0)
• ✅ npm run lint - PASSED (0 errors, 236 pre-existing warnings)

Verification

• ✅ No direct Supabase queries for agreements table in agreements.service.ts
• ✅ No direct Supabase queries for agreement_activity table in agreements.service.ts
• ✅ No direct Supabase queries for agreements table in disputes.service.ts
• ✅ All data access flows through AgreementsBackendClient

Migration Notes

For Disputes Service

The disputes service continues to work without changes to its public interface:

• updateAgreementStatus() is internally called via the backend client
• logAgreementActivity() is internally called via the backend client
• No changes needed in code that depends on disputes service

For Other Services

Other services that consume agreements data should be updated in separate PRs:

• webhooks.service.ts - handles blockchain events (may need backend relay)
• notifications.service.ts - fetches agreement metadata
• agreement-chat.service.ts - validates agreement access
• wallets.service.ts - checks agreement participants

Checklist

• Code follows project style guidelines
• Self-review of changes completed
• Comments added for complex logic
• Documentation updated
• No new warnings introduced
• All tests pass
• Backward compatibility maintained
• No breaking changes to public APIs

[vercel]

@SudiptaPaul-31 is attempting to deploy a commit to the ManuelJG's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Kalchaqui]

Review — changes requested (do not merge)

Thanks for the effort, @SudiptaPaul-31 — but this PR does not implement #10.

Blocker 1: wrong layer / wrong repo

Issue Thalos-Infrastructure/ThalosFrontend#102 asks for a Frontend migration:

• create lib/api/agreements.ts in ThalosFrontend
• migrate consumers off lib/actions/agreements.ts
• remove FE supabase.from("agreements") / agreement_activity

This PR changes Nest (AgreementsService → HTTP client). The FE work is still undone (lib/api/agreements.ts does not exist; lib/actions/agreements.ts still hits Supabase).

Please open the PR against ThalosFrontend, following the existing pattern in lib/api/disputes.ts / lib/api/wallets.ts.

Blocker 2: circular self-HTTP call

AgreementsService now calls AgreementsBackendClient, which hardcodes http://localhost:3001 and hits Nest /agreements/* again. That means the Nest agreements module would call itself over HTTP — recursion / wrong architecture. Nest should keep talking to Supabase (or an internal data layer); the HTTP client belongs on the frontend (or another service), not inside the same service that owns the routes.

Blocker 3: wrong list route

Client uses GET /agreements?wallet= — the real route (see #62) is GET /agreements/by-wallet?wallet=.

Other

• Unrelated agreement-chat commits (07c23ab, 76e9a9f) should not ride along on this issue.
• Prefer a clean FE PR only for Create lib/api/agreements.tsand migrate agreements off Supabase ThalosFrontend#102.

Happy to re-review once there’s a Frontend PR that maps to the real Nest endpoints and clears the Supabase greps.