# Rivet Sample Validation and Observed Drift

Validated sources:
- `zoom/rivet-javascript-sample`
- `zoom/isv-rivet-starter`
- `zoom/Rivet-Server-Sample`
- `zoom/rivet-javascript`

## Lifecycle Patterns Confirmed

- Module clients are instantiated with auth + receiver options.
- Handlers are registered before or near startup.
- `client.start()` bootstraps receiver/server.
- Multi-module samples use unique ports per module.
- `/zoom/events` endpoint suffix is required for webhook callbacks.

## Architecture Patterns Confirmed

- Rivet acts as an orchestration layer:
- Typed endpoint wrappers for API operations.
- Webhook consumer methods for events.
- OAuth helper behavior embedded in client lifecycle.

## Useful Additions Incorporated into Skill

- Multi-module port segregation and webhook endpoint mapping.
- Distinct auth patterns by module.
- Sample-derived operational gotchas for ngrok and OAuth install.

## Contradictions and Drift Notes

- Some docs/samples reference older Team Chat doc paths (`team-chat-apps`) while current docs may use updated routing.
- Sample env variable naming is inconsistent across repos (`StS_*`, `WEBHOOK_SECRET_TOKEN`, per-module keys). This skill standardizes names in `environment-variables.md`.
- Some sample README commands imply one port while module receivers may actually use `base+1` or per-module ports.
- User OAuth behavior depends on receiver choice; `AwsLambdaReceiver` limitations must be handled explicitly.

## Recommendations

- Keep a local compatibility table: `rivet_version` x `modules_used` x `auth_flows` x `receiver_type`.
- Treat sample repos as patterns, not strict source of truth.
- Re-check TypeDoc and changelog before each release.