availsync 0.1.0

package/.zencoder/skills/stripe-best-practices/references/treasury.md

@@ -0,0 +1,16 @@
+# Treasury / Financial Accounts
+
+## Table of contents
+
+- v2 Financial Accounts API
+- Legacy v1 Treasury
+
+## v2 Financial Accounts API
+
+For embedded financial accounts (bank accounts, account and routing numbers, money movement), use the [v2 Financial Accounts API](https://docs.stripe.com/api/v2/core/vault/financial-accounts.md) (`POST /v2/core/vault/financial_accounts`). This is required for new integrations.
+
+For Treasury for platforms concepts and guides, see the [Treasury for platforms overview](https://docs.stripe.com/treasury/connect.md).
+
+## Legacy v1 Treasury
+
+Don’t use the [v1 Treasury Financial Accounts API](https://docs.stripe.com/api/treasury/financial_accounts.md) (`POST /v1/treasury/financial_accounts`) for new integrations. Existing v1 integrations continue to work.

package/.zencoder/skills/stripe-projects/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: stripe-projects
+description: >-
+  Use when the user needs to provision a third-party service available on
+  https://projects.dev/providers; create or retrieve a provider/service API, key
+  or token; sign up for a service; or references projects.dev. Handles the full
+  flow from checking provider availability through project initialization, then
+  hands off to locally installed skills.
+allowed-tools:
+  - Bash(stripe *)
+  - Bash(which stripe)
+  - Bash(brew install stripe/stripe-cli/stripe)
+  - Bash(brew upgrade stripe/stripe-cli/stripe)
+  - Bash(scoop bucket add stripe https://github.com/stripe/scoop-stripe-cli.git)
+  - Bash(scoop install stripe)
+  - Bash(sudo apt *)
+  - Bash(curl -s https://packages.stripe.dev/*)
+  - WebFetch
+  - Skill
+  - Read
+
+---
+
+## Stripe Projects — Service Provisioning
+
+Provision third-party services and retrieve API keys/tokens using the Stripe Projects CLI plugin.
+
+## Workflow
+
+### Step 1: Verify Provider Availability
+
+Before doing anything else, fetch `https://projects.dev/providers` and check whether the requested provider appears in the directory listing.
+
+- If the provider **isn’t listed** on that page, inform the user that Stripe Projects **doesn’t support** this provider and stop.
+- If the provider **is listed**, continue.
+
+### Step 2: Ensure Stripe CLI is Installed
+
+Check if the Stripe CLI is available:
+
+```bash
+which stripe && stripe --version
+```
+
+If not installed, install based on the user’s platform:
+
+**macOS (Homebrew):**
+
+```bash
+brew install stripe/stripe-cli/stripe
+```
+
+**Linux (Debian/Ubuntu via APT):**
+
+```bash
+curl -s https://packages.stripe.dev/api/security/keypair/stripe-cli-gpg/public | gpg --dearmor | sudo tee /usr/share/keyrings/stripe.gpg > /dev/null
+echo "deb [signed-by=/usr/share/keyrings/stripe.gpg] https://packages.stripe.dev/stripe-cli-debian-local stable main" | sudo tee -a /etc/apt/sources.list.d/stripe.list
+sudo apt update
+sudo apt install stripe
+```
+
+**Windows (Scoop):**
+
+```bash
+scoop bucket add stripe https://github.com/stripe/scoop-stripe-cli.git
+scoop install stripe
+```
+
+If installed, but the version is lower than 1.40.0, then upgrade based on the user’s platform:
+
+**macOS (Homebrew):**
+
+```bash
+brew upgrade stripe/stripe-cli/stripe
+```
+
+or follow instructions at https://docs.stripe.com/stripe-cli/upgrade for other platforms.
+
+### Step 3: Ensure Stripe Projects Plugin is Installed and on Latest
+
+```bash
+stripe plugin install projects
+```
+
+### Step 4: Search the Catalog
+
+Confirm the specific provider is available and validates the specific service:
+
+```bash
+stripe projects search <query> --json
+```
+
+If `result_count` is 0, inform the user the service was not found in the catalog and stop.
+
+### Step 5: Initialize a Project
+
+Check if a project is already initialized:
+
+```bash
+stripe projects status --json
+```
+
+If not initialized:
+
+```bash
+stripe projects init --json --yes
+```
+
+Note: If the user hasn’t logged in to the Stripe CLI, `projects init` will redirect them to a browser to either log in to an existing Stripe account or create a new Stripe Projects account. When this happens, prompt the user:
+
+> ▎ Stripe Projects is redirecting you to the browser to authenticate. ▎ - If you have an existing Stripe account, log in with your credentials. ▎ - If you’re new, you can create a free Stripe Projects account in seconds. ▎ ▎ Complete the sign-in in your browser, then come back here and let me know when you’re done.
+
+Wait for the user to confirm before proceeding.
+
+### Step 6: Hand Off to local stripe-projects-cli skill
+
+Important: After the project is initialized, always use the `stripe-projects-cli` skill installed at `.claude/skills/stripe-projects-cli` in the local project directory (invoke via the Skill tool with name `stripe-projects-cli`) to continue the workflow for adding services. Print out the env variable names returned in a table, but never their values.
+
+### Step 7: Provider Recommendations
+
+After a successful ‘add’ output, you must give the user helpful suggestions on other providers services available on Stripe Projects catalog that could be complementary (different primary category) or helpful - 3 to 5 suggestions. NEVER show fabricated commands to provision these services, only ones from the `stripe projects catalog` output if at all.
+
+## Non-Interactive Mode
+
+Always use `--json --yes` flags to suppress interactive prompts. If a paid service requires confirmation, add `--confirm-paid-service`.
+
+## Working Agreement
+
+- Don’t hand-edit CLI-managed files under `.projects` or the generated `.env` output.
+- NEVER look at any files in the .projects directory. The CLI manages everything for you.
+- NEVER look at the .env file. The CLI manages everything for you.
+
+## Error Handling
+
+- Provider not listed at `projects.dev/providers` → stop early, tell the user it’s not supported
+- Stripe CLI missing → install per platform instructions above
+- Plugin missing → install via `stripe plugin install projects`
+- `projects init` triggers browser login → prompt user, wait for confirmation
+- Service not in catalog → inform user, suggest `stripe projects catalog --json` to browse alternatives

package/.zencoder/skills/upgrade-stripe/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: upgrade-stripe
+description: Guide for upgrading Stripe API versions and SDKs
+
+---
+
+The latest Stripe API version is 2026-04-22.dahlia - use this version when upgrading unless the user specifies a different target version.
+
+# Upgrading Stripe Versions
+
+This guide covers upgrading Stripe API versions, server-side SDKs, Stripe.js, and mobile SDKs.
+
+## Understanding Stripe API Versioning
+
+Stripe uses date-based API versions (e.g., `2026-04-22.dahlia`, `2025-08-27.basil`, `2024-12-18.acacia`). Your account’s API version determines request/response behavior.
+
+### Types of Changes
+
+**Backward-Compatible Changes** (don’t require code updates):
+
+- New API resources
+- New optional request parameters
+- New properties in existing responses
+- Changes to opaque string lengths (e.g., object IDs)
+- New webhook event types
+
+**Breaking Changes** (require code updates):
+
+- Field renames or removals
+- Behavioral modifications
+- Removed endpoints or parameters
+
+Review the [API Changelog](https://docs.stripe.com/changelog.md) for all changes between versions.
+
+## Server-Side SDK Versioning
+
+See [SDK Version Management](https://docs.stripe.com/sdks/set-version.md) for details.
+
+### Dynamically-Typed Languages (Ruby, Python, PHP, Node.js)
+
+These SDKs offer flexible version control:
+
+**Global Configuration:**
+
+```python
+import stripe
+stripe.api_version = '2026-04-22.dahlia'
+```
+
+```ruby
+Stripe.api_version = '2026-04-22.dahlia'
+```
+
+```javascript
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'
+});
+```
+
+**Per-Request Override:**
+
+```python
+stripe.Customer.create(
+  email="customer@example.com",
+  stripe_version='2026-04-22.dahlia'
+)
+```
+
+### Strongly-Typed Languages (Java, Go, .NET)
+
+These use a fixed API version matching the SDK release date. Don’t set a different API version for strongly-typed languages because response objects might not match the strong types in the SDK. Instead, update the SDK to target a new API version.
+
+### Best Practice
+
+Always specify the API version you’re integrating against in your code instead of relying on your account’s default API version:
+
+```javascript
+// Good: Explicit version
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'
+});
+
+// Avoid: Relying on account default
+const stripe = require('stripe')('sk_test_xxx');
+```
+
+## Stripe.js Versioning
+
+See [Stripe.js Versioning](https://docs.stripe.com/sdks/stripejs-versioning.md) for details.
+
+Stripe.js uses an evergreen model with major releases (Acacia, Basil, Clover, Dahlia) on a biannual basis.
+
+### Loading Versioned Stripe.js
+
+**Via Script Tag:**
+
+```html
+<script src="https://js.stripe.com/dahlia/stripe.js"></script>
+```
+
+**Via npm:**
+
+```bash
+npm install @stripe/stripe-js
+```
+
+Major npm versions correspond to specific Stripe.js versions.
+
+### API Version Pairing
+
+Each Stripe.js version automatically pairs with its corresponding API version. For instance:
+
+- Dahlia Stripe.js uses `2026-04-22.dahlia` API
+- Acacia Stripe.js uses `2024-12-18.acacia` API
+
+You can’t override this association.
+
+### Migrating from v3
+
+1. Identify your current API version in code
+1. Review the changelog for relevant changes
+1. Consider gradually updating your API version before switching Stripe.js versions
+1. Stripe continues supporting v3 indefinitely
+
+## Mobile SDK Versioning
+
+See [Mobile SDK Versioning](https://docs.stripe.com/sdks/mobile-sdk-versioning.md) for details.
+
+### iOS and Android SDKs
+
+Both platforms follow **semantic versioning** (MAJOR.MINOR.PATCH):
+
+- **MAJOR**: Breaking API changes
+- **MINOR**: New functionality (backward-compatible)
+- **PATCH**: Bug fixes (backward-compatible)
+
+New features and fixes release only on the latest major version. Upgrade regularly to access improvements.
+
+### React Native SDK
+
+Uses a different model (0.x.y schema):
+
+- **Minor version changes** (x): Breaking changes AND new features
+- **Patch updates** (y): Critical bug fixes only
+
+### Backend Compatibility
+
+All mobile SDKs work with any Stripe API version you use on your backend unless documentation specifies otherwise.
+
+## Upgrade Checklist
+
+1. Review the [API Changelog](https://docs.stripe.com/changelog.md) for changes between your current and target versions
+1. Check [Upgrades Guide](https://docs.stripe.com/upgrades.md) for migration guidance
+1. Update server-side SDK package version (e.g., `npm update stripe`, `pip install --upgrade stripe`)
+1. Update the `apiVersion` parameter in your Stripe client initialization
+1. Test your integration against the new API version using the `Stripe-Version` header
+1. Update webhook handlers to handle new event structures
+1. Update Stripe.js script tag or npm package version if needed
+1. Update mobile SDK versions in your package manager if needed
+1. Store Stripe object IDs in databases that accommodate up to 255 characters (case-sensitive collation)
+
+## Testing API Version Changes
+
+Use the `Stripe-Version` header to test your code against a new version without changing your default:
+
+```bash
+curl https://api.stripe.com/v1/customers \
+  -u sk_test_xxx: \
+  -H "Stripe-Version: 2026-04-22.dahlia"
+```
+
+Or in code:
+
+```javascript
+const stripe = require('stripe')('sk_test_xxx', {
+  apiVersion: '2026-04-22.dahlia'  // Test with new version
+});
+```
+
+## Important Notes
+
+- Your webhook listener should handle unfamiliar event types gracefully
+- Test webhooks with the new version structure before upgrading
+- Breaking changes are tagged by affected product areas (Payments, Billing, Connect, etc.)
+- Multiple API versions coexist simultaneously, enabling staged adoption

package/AUDIT.md

@@ -0,0 +1,95 @@
+# Availsync Codebase Audit
+
+**Date:** 2026-05-11
+**Auditor:** Claude Code
+
+---
+
+## Build & Test Status
+
+- `npm run build` (tsc): **PASS** — zero TypeScript errors and compiled `dist/`
+- Backend unit tests: **PASS** — 14/14 tests green across 3 suites
+- Backend integration tests: require a running PostgreSQL database via `TEST_DATABASE_URL`
+
+---
+
+## What Is Built and Working
+
+### Backend (Express + PostgreSQL)
+- **Database schema** (001_init.sql): 7 tables with proper constraints, indices, and FK cascades
+- **Auth middleware**: bcrypt-based API key verification (O(n) scan — correct but slow at scale)
+- **Org management**: POST /v1/orgs, POST /v1/orgs/:id/agents (with agent_limit enforcement returning 402), GET /v1/orgs/:id/agents
+- **Availability engine**: GET /v1/availability (slot generation with buffer, focus block, and confidence scoring), POST/GET /v1/availability-windows
+- **Holds with conflict resolution**: POST /v1/holds (pg_advisory_xact_lock + SELECT FOR UPDATE SKIP LOCKED), DELETE /v1/holds/:id, GET /v1/holds
+- **Conflict resolution**: deterministic priority ladder (priority_over_agents > agent_type rank > priority field > first-come-first-served)
+- **Preferences**: GET/PUT /v1/preferences/:agent_id with Zod validation
+- **Session**: GET /v1/session (restores org/agent from API key)
+- **Billing**: POST /v1/billing/checkout (Stripe Checkout Session), GET /v1/billing/subscription/:org_id, POST /v1/billing/webhook (signature verification, plan upgrades/downgrades)
+- **MCP server**: 3 tools (check_availability, book_slot, release_slot) via stdio transport
+- **Coolify Git deploy**: frontend and API served by one Nixpacks app; PostgreSQL should be a Coolify service
+- **Smoke tests**: 7 curl-based checks in tests/smoke.sh
+
+### Frontend (Next.js 15 + React 19 + Tailwind)
+- **Marketing pages**: Homepage, Pricing, Docs, Quickstart
+- **Auth flows**: Signup (org creation), Login (API key restore), Checkout (Stripe redirect)
+- **Dashboard**: Overview (metric cards), Agents list, Availability checker, Hold management, Onboarding
+- **Playwright smoke tests**: 4 tests covering homepage, pricing, docs, and full E2E flow
+
+---
+
+## What Is Broken or Incomplete
+
+1. **Agent limits don't match spec**: billing.ts uses `{free:3, individual:10, team:50}` — spec says `{free:3, individual:15, team:9999}`
+2. **Pricing mismatch**: frontend plans.ts shows $19/$49 — spec says $10/$25
+3. **No environment validation**: server starts without checking required env vars
+4. **No helmet or cors package**: CORS is hand-rolled and incomplete (no credentials support)
+5. **No rate limiting**: any client can flood the API
+6. **No global error handler**: unhandled exceptions crash without structured response
+7. **No structured logging**: raw console.log/console.error throughout
+8. **No auto-migrations**: migrations require manual `psql` command
+9. **DELETE /v1/holds/:id scoped to agent only**: requires both agent_id AND org_id match — other agents in same org cannot release each other's holds (may be intentional but limits admin use)
+10. **Frontend sidebar has no active state**: current page not highlighted
+11. **Frontend uses light theme**: spec requires Linear-style dark UI
+12. **No Geist font**: uses system font stack
+13. **Agent detail page is a stub**: shows only agentId placeholder
+
+---
+
+## What Is Missing Entirely
+
+### Backend
+- `GET /v1/audit` route (hold_events with agent name join, pagination)
+- `GET /v1/billing/portal` (Stripe Customer Portal session)
+- `GET /v1/billing/status` (plan, usage, renewal date)
+- `stripe_customer_id` and `stripe_subscription_id` columns on orgs table
+- `invoice.payment_failed` webhook event handling
+- Migration 002_stripe.sql
+- `src/lib/logger.ts` (structured JSON logging)
+- Rate limiting middleware
+- Helmet security headers
+- Environment validation at startup
+- Coolify production env configuration
+
+### Frontend
+- Dark theme (Linear-style) design system
+- Geist / Geist Mono fonts
+- Overview page with real metrics (holds today, conflicts 24h, API calls 7d)
+- Agents page: inline edit, revoke, API key masking, copy-to-clipboard
+- Availability page: weekly grid view, preferences panel
+- Audit Log page (full-width table with filters)
+- Settings page: Account, Billing, API tabs
+- UI components: Badge, KeyDisplay, EmptyState, ConfirmDialog, Toast, Skeleton
+- Keyboard shortcuts (N, ?, Cmd+K, Escape)
+- Command palette
+- Loading skeleton states
+- Proper 3-step onboarding flow at /dashboard/setup
+
+### Tests
+- Flow C automated test (multi-agent conflict resolution)
+- PRODUCTION_CHECKLIST.md
+
+---
+
+## Summary
+
+The core scheduling engine is solid — conflict resolution, availability calculation, and the database schema are well-designed. The main gaps are production hardening (security, logging, env validation), missing billing infrastructure (portal, status, Stripe customer tracking), and the frontend which needs a complete visual overhaul from light/warm to dark/Linear-style plus several missing pages and components.

package/COOLIFY.md

@@ -0,0 +1,51 @@
+# Coolify Git deploy
+
+This repo is configured for Coolify Git deployments with the Nixpacks build pack.
+Do not use Dockerfile or Docker Compose build packs for this project.
+
+Coolify still runs applications in containers internally, but these settings avoid
+custom Dockerfiles and Compose files in the repository.
+
+## Single Coolify application
+
+Create one Coolify application from this Git repository. The same Node process
+serves both the Next.js frontend and the Express API:
+
+- Frontend routes: `/`, `/app`, `/pricing`, `/docs`, etc.
+- API routes: `/v1/*`
+- Health check: `/health`
+
+- Source directory: `/`
+- Build pack: `Nixpacks`
+- Port: `3000`
+- Health check path: `/health`
+- Build command: leave empty, Nixpacks reads `nixpacks.toml`
+- Start command: leave empty, Nixpacks reads `nixpacks.toml`
+- Keep `NODE_ENV=production` as runtime only in Coolify. Do not mark it
+  "Available at Buildtime"; Nixpacks needs dev dependencies during the build.
+
+Required environment variables:
+
+```text
+DATABASE_URL=postgresql://...
+PORT=3000
+NODE_ENV=production
+API_KEY_SALT_ROUNDS=10
+SESSION_SECRET=replace-with-a-long-random-secret
+CORS_ORIGINS=https://your-app-domain.example
+STRIPE_SECRET_KEY=sk_live_...
+STRIPE_WEBHOOK_SECRET=whsec_...
+STRIPE_PRICE_INDIVIDUAL=price_...
+STRIPE_PRICE_TEAM=price_...
+APP_URL=https://your-app-domain.example
+FRONTEND_URL=https://your-app-domain.example
+NEXT_PUBLIC_APP_URL=https://your-app-domain.example
+```
+
+Do not set `NEXT_PUBLIC_API_URL` for the single-deployment setup. The frontend
+uses relative `/v1/*` API calls on the same domain.
+
+## Database
+
+Use a Coolify PostgreSQL service and copy its connection string into this app as
+`DATABASE_URL`. The API runs migrations automatically on startup.

package/MCP_SETUP.md

@@ -0,0 +1,23 @@
+# Tilslut Availsync MCP
+
+Brug den public alpha-pakke. Du skal ikke clone Availsync repoet for at bruge MCP-serveren.
+
+Tilfoej til `~/Library/Application Support/Claude/claude_desktop_config.json` eller tilsvarende MCP config:
+
+```json
+{
+  "mcpServers": {
+    "availsync": {
+      "command": "npx",
+      "args": ["-y", "@availsync/mcp@alpha"],
+      "env": {
+        "AVAILSYNC_API_URL": "https://availsync.dev",
+        "AVAILSYNC_AGENT_ID": "AGENT_ID",
+        "AVAILSYNC_API_KEY": "API_KEY"
+      }
+    }
+  }
+}
+```
+
+`AVAILSYNC_AGENT_ID` er default agent for tool calls. Tool input kan stadig override `agent_id`, hvis du bruger flere roller.