Local Environment Management
Help with local development environment tasks for daily-api.
Database Access
PostgreSQL runs locally via Docker in a k8s container.
Finding the Container
docker ps --format "table {{.Names}}" | grep "k8s_app_postgres"
Running Queries
docker exec <CONTAINER_NAME> psql -U postgres -d api -c "YOUR SQL QUERY"
For multi-line queries:
docker exec <CONTAINER_NAME> psql -U postgres -d api <<'EOF' SELECT * FROM users LIMIT 1; EOF
Fake Payment Setup
Payment status for opportunities is tracked on the Organization level via recruiterSubscriptionFlags. Opportunities also store subscription info in their flags column.
Organization Subscription Fields
| Field | Description |
|---|---|
status | Must be 'active' for payment validation to pass |
provider | Use 'paddle' |
items[].quantity | Number of opportunity "seats" available |
items[].priceId | Price ID that opportunities reference |
Opportunity Flags Fields
| Field | Description |
|---|---|
plan | Must match a priceId from the org's subscription items |
batchSize | Number of candidates per batch |
Fake Payment for Organization
UPDATE organization
SET "recruiterSubscriptionFlags" = jsonb_build_object(
'status', 'active',
'provider', 'paddle',
'subscriptionId', 'fake_sub_123',
'createdAt', now(),
'updatedAt', now(),
'items', jsonb_build_array(
jsonb_build_object('priceId', 'pri_fake_123', 'quantity', 5)
)
)
WHERE id = 'ORGANIZATION_ID';
Reset: UPDATE organization SET "recruiterSubscriptionFlags" = '{}' WHERE id = 'ORGANIZATION_ID';
Fake Payment for Opportunity
Requires updating both the organization AND the opportunity:
-- Step 1: Update organization subscription
UPDATE organization
SET "recruiterSubscriptionFlags" = jsonb_build_object(
'status', 'active',
'provider', 'paddle',
'subscriptionId', 'fake_sub_123',
'createdAt', now(),
'updatedAt', now(),
'items', jsonb_build_array(
jsonb_build_object('priceId', 'pri_fake_123', 'quantity', 5)
)
)
WHERE id = (SELECT "organizationId" FROM opportunity WHERE id = 'OPPORTUNITY_ID');
-- Step 2: Update opportunity flags
UPDATE opportunity
SET flags = flags || jsonb_build_object(
'plan', 'pri_fake_123',
'batchSize', 50
)
WHERE id = 'OPPORTUNITY_ID';
Reset:
UPDATE organization SET "recruiterSubscriptionFlags" = '{}'
WHERE id = (SELECT "organizationId" FROM opportunity WHERE id = 'OPPORTUNITY_ID');
UPDATE opportunity SET flags = flags - 'plan' - 'batchSize'
WHERE id = 'OPPORTUNITY_ID';
Opportunity State Management
The opportunity table uses a state column (integer) to track lifecycle status. Values come from OpportunityState enum in @dailydotdev/schema.
OpportunityState Values
| Value | Name | Description |
|---|---|---|
| 0 | UNSPECIFIED | Default/unset |
| 1 | DRAFT | Not yet published |
| 2 | LIVE | Active and visible |
| 3 | CLOSED | No longer active |
| 4 | IN_REVIEW | Pending review |
Update Opportunity State
-- Set to LIVE UPDATE opportunity SET state = 2 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title; -- Set to DRAFT UPDATE opportunity SET state = 1 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title; -- Set to CLOSED UPDATE opportunity SET state = 3 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title; -- Set to IN_REVIEW UPDATE opportunity SET state = 4 WHERE id = 'OPPORTUNITY_ID' RETURNING id, state, title;
Instructions
When the user asks for local environment help:
- •For SQL queries: First find the postgres container, then execute via docker exec
- •For fake payments: Determine if they're providing an opportunity ID or organization ID, run the appropriate SQL
- •Always verify: After changes, run a SELECT to confirm
- •Ask if unclear: If the request is ambiguous, ask clarifying questions
Common requests:
- •"Set up fake payment for opportunity X" → Run both org and opportunity updates
- •"Set up fake payment for org X" → Run only org update
- •"Run SQL: ..." → Execute via docker
- •"Reset payment for X" → Run reset queries
- •"Check subscription for X" → Query and display current state
- •"Update opp X to live/draft/closed" → Update opportunity state
Discovering Schema Information
When handling requests not covered in this skill, use these techniques to discover the correct schema:
1. Check Entity Definitions
Entity files define column names and types:
# Find the entity file grep -r "TableName" src/entity/ --include="*.ts" # Read the entity to see column definitions
Key location: src/entity/ - TypeORM entities with @Column decorators show actual DB column names.
2. Find Enum Values
Many columns use integer enums from @dailydotdev/schema. To find enum values:
# Search for enum usage in codebase grep -r "EnumName\." src/ --include="*.ts" | head -20 # Find enum definition in schema package grep -r "EnumName" node_modules/@dailydotdev/schema/dist/ --include="*.d.ts"
Common enum locations: node_modules/@dailydotdev/schema/dist/daily-api/*_pb.d.ts
3. Query Existing Data
When unsure about column names or values:
-- Check table structure \d tablename -- See existing values SELECT DISTINCT column_name FROM tablename LIMIT 10; -- Inspect a specific row SELECT * FROM tablename WHERE id = 'xxx' LIMIT 1;
4. Common Gotchas
- •Column naming: Entity property names may differ from DB columns (e.g.,
statenotstatus) - •Integer enums: Many "status" fields are integers, not strings - find the enum definition
- •JSONB fields: Use
jsonb_build_object()for updates,->or->>for queries - •Quoted columns: PostgreSQL requires double quotes for camelCase columns (e.g.,
"organizationId")
Continuous Improvement
This skill should evolve over time. When you discover new local environment operations, common testing patterns, or useful queries:
- •Add them to this file - Update the SKILL.md with new sections or examples
- •Keep it practical - Focus on operations that are frequently needed
- •Document the why - Explain what fields mean and why certain values are used
If a user asks for something not covered here, help them and then offer to add it to this skill for future use.