zilmate 1.7.2 → 1.7.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.env.example +36 -36
- package/README.md +503 -503
- package/SDK.md +320 -320
- package/agent-docs.md +276 -276
- package/dist/agents/automation-planner.agent.d.ts.map +1 -1
- package/dist/agents/coding.agent.d.ts +18 -0
- package/dist/agents/coding.agent.d.ts.map +1 -1
- package/dist/agents/finance.agent.d.ts +60 -0
- package/dist/agents/finance.agent.d.ts.map +1 -0
- package/dist/agents/finance.agent.js +30 -0
- package/dist/agents/finance.agent.js.map +1 -0
- package/dist/agents/manager.d.ts +94 -1
- package/dist/agents/manager.d.ts.map +1 -1
- package/dist/agents/manager.js +102 -36
- package/dist/agents/manager.js.map +1 -1
- package/dist/agents/swarm/engineering/qa.d.ts +3 -0
- package/dist/agents/swarm/engineering/qa.d.ts.map +1 -0
- package/dist/agents/swarm/engineering/qa.js +19 -0
- package/dist/agents/swarm/engineering/qa.js.map +1 -0
- package/dist/agents/swarm/growth/seo.d.ts +3 -0
- package/dist/agents/swarm/growth/seo.d.ts.map +1 -0
- package/dist/agents/swarm/growth/seo.js +19 -0
- package/dist/agents/swarm/growth/seo.js.map +1 -0
- package/dist/agents/swarm/main.d.ts +22 -0
- package/dist/agents/swarm/main.d.ts.map +1 -0
- package/dist/agents/swarm/main.js +65 -0
- package/dist/agents/swarm/main.js.map +1 -0
- package/dist/agents/swarm/operations/finance.d.ts +3 -0
- package/dist/agents/swarm/operations/finance.d.ts.map +1 -0
- package/dist/agents/swarm/operations/finance.js +19 -0
- package/dist/agents/swarm/operations/finance.js.map +1 -0
- package/dist/agents/swarm/registry.d.ts +4 -0
- package/dist/agents/swarm/registry.d.ts.map +1 -0
- package/dist/agents/swarm/registry.js +361 -0
- package/dist/agents/swarm/registry.js.map +1 -0
- package/dist/cli/composer.d.ts.map +1 -1
- package/dist/cli/composer.js +54 -4
- package/dist/cli/composer.js.map +1 -1
- package/dist/cli/doctor.d.ts.map +1 -1
- package/dist/cli/doctor.js +13 -0
- package/dist/cli/doctor.js.map +1 -1
- package/dist/cli/format.d.ts.map +1 -1
- package/dist/cli/format.js +46 -24
- package/dist/cli/format.js.map +1 -1
- package/dist/cli/interactive.d.ts.map +1 -1
- package/dist/cli/interactive.js +47 -3
- package/dist/cli/interactive.js.map +1 -1
- package/dist/cli/render.d.ts.map +1 -1
- package/dist/cli/render.js +18 -9
- package/dist/cli/render.js.map +1 -1
- package/dist/cli/setup.d.ts +1 -0
- package/dist/cli/setup.d.ts.map +1 -1
- package/dist/cli/setup.js +74 -2
- package/dist/cli/setup.js.map +1 -1
- package/dist/cli/swarm.d.ts +4 -0
- package/dist/cli/swarm.d.ts.map +1 -0
- package/dist/cli/swarm.js +21 -0
- package/dist/cli/swarm.js.map +1 -0
- package/dist/cli/theme.d.ts +9 -0
- package/dist/cli/theme.d.ts.map +1 -1
- package/dist/cli/theme.js +36 -0
- package/dist/cli/theme.js.map +1 -1
- package/dist/cli/tunnel.d.ts.map +1 -1
- package/dist/cli/tunnel.js +2 -1
- package/dist/cli/tunnel.js.map +1 -1
- package/dist/cli/voice.js +11 -11
- package/dist/cli/welcome.d.ts.map +1 -1
- package/dist/cli/welcome.js +2 -0
- package/dist/cli/welcome.js.map +1 -1
- package/dist/index.js +19 -1
- package/dist/index.js.map +1 -1
- package/dist/jobs/anomaly.js +5 -5
- package/dist/memory/heal.js +43 -43
- package/dist/observability/doctor.d.ts +3 -0
- package/dist/observability/doctor.d.ts.map +1 -0
- package/dist/observability/doctor.js +33 -0
- package/dist/observability/doctor.js.map +1 -0
- package/dist/observability/usage.d.ts +13 -0
- package/dist/observability/usage.d.ts.map +1 -0
- package/dist/observability/usage.js +34 -0
- package/dist/observability/usage.js.map +1 -0
- package/dist/runtime/confirm.d.ts.map +1 -1
- package/dist/runtime/confirm.js +12 -2
- package/dist/runtime/confirm.js.map +1 -1
- package/dist/runtime/prompts/builder.d.ts +11 -0
- package/dist/runtime/prompts/builder.d.ts.map +1 -0
- package/dist/runtime/prompts/builder.js +29 -0
- package/dist/runtime/prompts/builder.js.map +1 -0
- package/dist/runtime/registry.d.ts +14 -0
- package/dist/runtime/registry.d.ts.map +1 -0
- package/dist/runtime/registry.js +39 -0
- package/dist/runtime/registry.js.map +1 -0
- package/dist/runtime/storage/interface.d.ts +16 -0
- package/dist/runtime/storage/interface.d.ts.map +1 -0
- package/dist/runtime/storage/interface.js +19 -0
- package/dist/runtime/storage/interface.js.map +1 -0
- package/dist/runtime/storage/local.d.ts +12 -0
- package/dist/runtime/storage/local.d.ts.map +1 -0
- package/dist/runtime/storage/local.js +48 -0
- package/dist/runtime/storage/local.js.map +1 -0
- package/dist/runtime/storage/redis.d.ts +11 -0
- package/dist/runtime/storage/redis.d.ts.map +1 -0
- package/dist/runtime/storage/redis.js +21 -0
- package/dist/runtime/storage/redis.js.map +1 -0
- package/dist/runtime/swarm/reports.d.ts +9 -0
- package/dist/runtime/swarm/reports.d.ts.map +1 -0
- package/dist/runtime/swarm/reports.js +43 -0
- package/dist/runtime/swarm/reports.js.map +1 -0
- package/dist/runtime/swarm.d.ts +37 -0
- package/dist/runtime/swarm.d.ts.map +1 -0
- package/dist/runtime/swarm.js +90 -0
- package/dist/runtime/swarm.js.map +1 -0
- package/dist/runtime/telemetry.d.ts +15 -0
- package/dist/runtime/telemetry.d.ts.map +1 -0
- package/dist/runtime/telemetry.js +25 -0
- package/dist/runtime/telemetry.js.map +1 -0
- package/dist/runtime/tool-utils.d.ts +12 -0
- package/dist/runtime/tool-utils.d.ts.map +1 -0
- package/dist/runtime/tool-utils.js +31 -0
- package/dist/runtime/tool-utils.js.map +1 -0
- package/dist/tools/browser.tool.d.ts +54 -0
- package/dist/tools/browser.tool.d.ts.map +1 -0
- package/dist/tools/browser.tool.js +193 -0
- package/dist/tools/browser.tool.js.map +1 -0
- package/dist/tools/business-apps.tool.d.ts +18 -0
- package/dist/tools/business-apps.tool.d.ts.map +1 -0
- package/dist/tools/business-apps.tool.js +43 -0
- package/dist/tools/business-apps.tool.js.map +1 -0
- package/dist/tools/computer-use.tool.js +66 -66
- package/dist/tools/cross-app-ledger.tool.d.ts +7 -0
- package/dist/tools/cross-app-ledger.tool.d.ts.map +1 -0
- package/dist/tools/cross-app-ledger.tool.js +70 -0
- package/dist/tools/cross-app-ledger.tool.js.map +1 -0
- package/dist/tools/desktop.tool.js +10 -10
- package/dist/tools/documents.tool.js +5 -5
- package/dist/tools/finance.tool.d.ts +18 -0
- package/dist/tools/finance.tool.d.ts.map +1 -0
- package/dist/tools/finance.tool.js +88 -0
- package/dist/tools/finance.tool.js.map +1 -0
- package/dist/tools/image-intelligence.tool.d.ts +12 -0
- package/dist/tools/image-intelligence.tool.d.ts.map +1 -0
- package/dist/tools/image-intelligence.tool.js +62 -0
- package/dist/tools/image-intelligence.tool.js.map +1 -0
- package/dist/tools/notify.tool.js +8 -8
- package/dist/tools/osint-install.tool.js +8 -8
- package/dist/tools/pentest-install.tool.js +6 -6
- package/dist/tools/setup-assistant.tool.d.ts +1 -1
- package/dist/tools/shell.tool.d.ts +18 -0
- package/dist/tools/shell.tool.d.ts.map +1 -1
- package/dist/tools/shell.tool.js +34 -0
- package/dist/tools/shell.tool.js.map +1 -1
- package/dist/tools/triggers.tool.d.ts.map +1 -1
- package/dist/tools/web-intelligence.tool.d.ts +12 -0
- package/dist/tools/web-intelligence.tool.d.ts.map +1 -0
- package/dist/tools/web-intelligence.tool.js +27 -0
- package/dist/tools/web-intelligence.tool.js.map +1 -0
- package/dist/workspace/init.js +18 -18
- package/dist/workspace/output-paths.d.ts +1 -1
- package/dist/workspace/output-paths.d.ts.map +1 -1
- package/dist/workspace/output-paths.js +1 -0
- package/dist/workspace/output-paths.js.map +1 -1
- package/dist/workspace/paths.d.ts +1 -0
- package/dist/workspace/paths.d.ts.map +1 -1
- package/dist/workspace/paths.js +1 -0
- package/dist/workspace/paths.js.map +1 -1
- package/install.ps1 +62 -62
- package/package.json +106 -103
- package/scripts/postinstall.mjs +42 -42
- package/scripts/release-github.mjs +91 -91
- package/src/doc/README.md +49 -49
- package/src/doc/admin-tools-and-sms-campaigns.md +99 -99
- package/src/doc/escalation-checklist.md +97 -97
- package/src/doc/payments-and-payouts.md +82 -82
- package/src/doc/shift-lifecycle-and-disputes.md +95 -95
- package/src/doc/support-macros.md +40 -40
- package/src/doc/venue-support-playbook.md +145 -145
- package/src/doc/verification-and-trust.md +88 -88
- package/src/doc/worker-support-playbook.md +159 -159
|
@@ -1,97 +1,97 @@
|
|
|
1
|
-
# Escalation Checklist
|
|
2
|
-
|
|
3
|
-
Use this checklist before escalating to engineering, operations, compliance, or payments.
|
|
4
|
-
|
|
5
|
-
## Required Information
|
|
6
|
-
|
|
7
|
-
- User type: worker or venue.
|
|
8
|
-
- User email or phone.
|
|
9
|
-
- Country.
|
|
10
|
-
- City/town.
|
|
11
|
-
- Page or feature.
|
|
12
|
-
- Exact error message.
|
|
13
|
-
- Time and date of issue.
|
|
14
|
-
- Browser/device if relevant.
|
|
15
|
-
- Screenshots if available.
|
|
16
|
-
|
|
17
|
-
## Shift Escalation
|
|
18
|
-
|
|
19
|
-
Include:
|
|
20
|
-
|
|
21
|
-
- Shift role.
|
|
22
|
-
- Shift date/time.
|
|
23
|
-
- Venue/company name.
|
|
24
|
-
- Worker name.
|
|
25
|
-
- Application status.
|
|
26
|
-
- Shift status.
|
|
27
|
-
- Clock-in/out records.
|
|
28
|
-
- Payment ID if available.
|
|
29
|
-
|
|
30
|
-
## Verification Escalation
|
|
31
|
-
|
|
32
|
-
Include:
|
|
33
|
-
|
|
34
|
-
- Country.
|
|
35
|
-
- Verification provider: Ghana/Hubtel or Didit.
|
|
36
|
-
- Current status.
|
|
37
|
-
- Whether front/back/liveness completed.
|
|
38
|
-
- Whether account name matches ID name.
|
|
39
|
-
- Any rejection reason.
|
|
40
|
-
|
|
41
|
-
Do not include full ID number in normal support tickets.
|
|
42
|
-
|
|
43
|
-
## Payment Escalation
|
|
44
|
-
|
|
45
|
-
Include:
|
|
46
|
-
|
|
47
|
-
- Provider: Hubtel, Paystack, Razorpay, Stripe.
|
|
48
|
-
- Amount and currency.
|
|
49
|
-
- Reference/checkout ID/payment ID.
|
|
50
|
-
- User ID.
|
|
51
|
-
- Shift ID if related.
|
|
52
|
-
- Provider response.
|
|
53
|
-
- Whether money was captured, pending, failed, refunded, or paid out.
|
|
54
|
-
|
|
55
|
-
## SMS Escalation
|
|
56
|
-
|
|
57
|
-
Include:
|
|
58
|
-
|
|
59
|
-
- Audience: workers, venues, or both.
|
|
60
|
-
- Test or batch.
|
|
61
|
-
- Sender ID.
|
|
62
|
-
- Normalized phone number.
|
|
63
|
-
- Hubtel response details.
|
|
64
|
-
- Gateway PM2 log line.
|
|
65
|
-
- Whether account has SMS credit.
|
|
66
|
-
|
|
67
|
-
## Fraud Or Abuse Escalation
|
|
68
|
-
|
|
69
|
-
Escalate immediately if:
|
|
70
|
-
|
|
71
|
-
- Duplicate accounts suspected.
|
|
72
|
-
- Same ID used by multiple accounts.
|
|
73
|
-
- Same payout account used by multiple unrelated workers.
|
|
74
|
-
- Referral farming suspected.
|
|
75
|
-
- Worker changes name around verification.
|
|
76
|
-
- Venue asks users to pay off-platform.
|
|
77
|
-
- Harassment, threats, unsafe venue, or unsafe worker behavior reported.
|
|
78
|
-
|
|
79
|
-
## Engineering Escalation Format
|
|
80
|
-
|
|
81
|
-
Use this format:
|
|
82
|
-
|
|
83
|
-
```text
|
|
84
|
-
Issue:
|
|
85
|
-
User type:
|
|
86
|
-
Country/city:
|
|
87
|
-
User ID/email:
|
|
88
|
-
Shift ID/payment ID:
|
|
89
|
-
Expected behavior:
|
|
90
|
-
Actual behavior:
|
|
91
|
-
Exact error:
|
|
92
|
-
Steps to reproduce:
|
|
93
|
-
Logs/response:
|
|
94
|
-
Impact:
|
|
95
|
-
Urgency:
|
|
96
|
-
```
|
|
97
|
-
|
|
1
|
+
# Escalation Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist before escalating to engineering, operations, compliance, or payments.
|
|
4
|
+
|
|
5
|
+
## Required Information
|
|
6
|
+
|
|
7
|
+
- User type: worker or venue.
|
|
8
|
+
- User email or phone.
|
|
9
|
+
- Country.
|
|
10
|
+
- City/town.
|
|
11
|
+
- Page or feature.
|
|
12
|
+
- Exact error message.
|
|
13
|
+
- Time and date of issue.
|
|
14
|
+
- Browser/device if relevant.
|
|
15
|
+
- Screenshots if available.
|
|
16
|
+
|
|
17
|
+
## Shift Escalation
|
|
18
|
+
|
|
19
|
+
Include:
|
|
20
|
+
|
|
21
|
+
- Shift role.
|
|
22
|
+
- Shift date/time.
|
|
23
|
+
- Venue/company name.
|
|
24
|
+
- Worker name.
|
|
25
|
+
- Application status.
|
|
26
|
+
- Shift status.
|
|
27
|
+
- Clock-in/out records.
|
|
28
|
+
- Payment ID if available.
|
|
29
|
+
|
|
30
|
+
## Verification Escalation
|
|
31
|
+
|
|
32
|
+
Include:
|
|
33
|
+
|
|
34
|
+
- Country.
|
|
35
|
+
- Verification provider: Ghana/Hubtel or Didit.
|
|
36
|
+
- Current status.
|
|
37
|
+
- Whether front/back/liveness completed.
|
|
38
|
+
- Whether account name matches ID name.
|
|
39
|
+
- Any rejection reason.
|
|
40
|
+
|
|
41
|
+
Do not include full ID number in normal support tickets.
|
|
42
|
+
|
|
43
|
+
## Payment Escalation
|
|
44
|
+
|
|
45
|
+
Include:
|
|
46
|
+
|
|
47
|
+
- Provider: Hubtel, Paystack, Razorpay, Stripe.
|
|
48
|
+
- Amount and currency.
|
|
49
|
+
- Reference/checkout ID/payment ID.
|
|
50
|
+
- User ID.
|
|
51
|
+
- Shift ID if related.
|
|
52
|
+
- Provider response.
|
|
53
|
+
- Whether money was captured, pending, failed, refunded, or paid out.
|
|
54
|
+
|
|
55
|
+
## SMS Escalation
|
|
56
|
+
|
|
57
|
+
Include:
|
|
58
|
+
|
|
59
|
+
- Audience: workers, venues, or both.
|
|
60
|
+
- Test or batch.
|
|
61
|
+
- Sender ID.
|
|
62
|
+
- Normalized phone number.
|
|
63
|
+
- Hubtel response details.
|
|
64
|
+
- Gateway PM2 log line.
|
|
65
|
+
- Whether account has SMS credit.
|
|
66
|
+
|
|
67
|
+
## Fraud Or Abuse Escalation
|
|
68
|
+
|
|
69
|
+
Escalate immediately if:
|
|
70
|
+
|
|
71
|
+
- Duplicate accounts suspected.
|
|
72
|
+
- Same ID used by multiple accounts.
|
|
73
|
+
- Same payout account used by multiple unrelated workers.
|
|
74
|
+
- Referral farming suspected.
|
|
75
|
+
- Worker changes name around verification.
|
|
76
|
+
- Venue asks users to pay off-platform.
|
|
77
|
+
- Harassment, threats, unsafe venue, or unsafe worker behavior reported.
|
|
78
|
+
|
|
79
|
+
## Engineering Escalation Format
|
|
80
|
+
|
|
81
|
+
Use this format:
|
|
82
|
+
|
|
83
|
+
```text
|
|
84
|
+
Issue:
|
|
85
|
+
User type:
|
|
86
|
+
Country/city:
|
|
87
|
+
User ID/email:
|
|
88
|
+
Shift ID/payment ID:
|
|
89
|
+
Expected behavior:
|
|
90
|
+
Actual behavior:
|
|
91
|
+
Exact error:
|
|
92
|
+
Steps to reproduce:
|
|
93
|
+
Logs/response:
|
|
94
|
+
Impact:
|
|
95
|
+
Urgency:
|
|
96
|
+
```
|
|
97
|
+
|
|
@@ -1,82 +1,82 @@
|
|
|
1
|
-
# Payments And Payouts
|
|
2
|
-
|
|
3
|
-
Use this guide to support billing setup, shift payment, worker payout, profile promotion, and country-specific payment rails.
|
|
4
|
-
|
|
5
|
-
## Payment Provider By Market
|
|
6
|
-
|
|
7
|
-
- Ghana: Hubtel for checkout, SMS, worker payout, and Ghana-specific flows.
|
|
8
|
-
- Nigeria, Kenya, South Africa: Paystack where configured.
|
|
9
|
-
- India: Razorpay.
|
|
10
|
-
- UK, US, and other markets: Stripe where configured.
|
|
11
|
-
|
|
12
|
-
## Venue Billing
|
|
13
|
-
|
|
14
|
-
Venues may need to connect billing before posting or paying for shifts.
|
|
15
|
-
|
|
16
|
-
Ghana venue billing:
|
|
17
|
-
|
|
18
|
-
- Uses Hubtel gateway `/api/checkout/initiate`.
|
|
19
|
-
- Requires gateway `SUPABASE_SERVICE_ROLE_KEY` to be a real service_role key.
|
|
20
|
-
- Requires Hubtel checkout credentials and account number.
|
|
21
|
-
- Writes checkout/payment state into `payments`.
|
|
22
|
-
|
|
23
|
-
Common errors:
|
|
24
|
-
|
|
25
|
-
- `SUPABASE_SERVICE_ROLE_KEY must have role service_role, not anon`: gateway env uses anon key. Replace with Supabase service role key and restart PM2.
|
|
26
|
-
- `Could not find worker_amount column`: live `payments` schema missing compatibility column. Add column and reload schema.
|
|
27
|
-
- Upstream 500: check gateway PM2 logs and Hubtel response body.
|
|
28
|
-
|
|
29
|
-
## Worker Payout
|
|
30
|
-
|
|
31
|
-
Workers must have valid payout details before payout can complete.
|
|
32
|
-
|
|
33
|
-
Ghana worker payout:
|
|
34
|
-
|
|
35
|
-
- Mobile money or bank details.
|
|
36
|
-
- Phone/account name should be verified where possible.
|
|
37
|
-
- Hubtel sends money or bank transfer through gateway.
|
|
38
|
-
|
|
39
|
-
Other markets:
|
|
40
|
-
|
|
41
|
-
- Paystack recipients/subaccounts for supported African countries.
|
|
42
|
-
- Razorpay fund accounts for India.
|
|
43
|
-
- Stripe Connect for Stripe markets.
|
|
44
|
-
|
|
45
|
-
## Profile Promotion
|
|
46
|
-
|
|
47
|
-
Workers can pay to promote their profile for 7 days.
|
|
48
|
-
|
|
49
|
-
Provider routing:
|
|
50
|
-
|
|
51
|
-
- Ghana: Hubtel checkout.
|
|
52
|
-
- Paystack countries: Paystack checkout.
|
|
53
|
-
- India: Razorpay checkout.
|
|
54
|
-
- Other markets: Stripe checkout.
|
|
55
|
-
|
|
56
|
-
If profile promotion payment succeeds but profile is not promoted:
|
|
57
|
-
|
|
58
|
-
- Check payment verification function for the provider.
|
|
59
|
-
- Check `profile_promotions`.
|
|
60
|
-
- Check `workers.promoted_until`.
|
|
61
|
-
- Escalate if provider captured payment but app did not update.
|
|
62
|
-
|
|
63
|
-
## Refunds And Disputes
|
|
64
|
-
|
|
65
|
-
Do not promise refunds until status is confirmed.
|
|
66
|
-
|
|
67
|
-
Escalate when:
|
|
68
|
-
|
|
69
|
-
- Worker no-show.
|
|
70
|
-
- Venue cancels after worker acceptance.
|
|
71
|
-
- Worker cancels after acceptance.
|
|
72
|
-
- Payment captured but shift canceled.
|
|
73
|
-
- Duplicate charge.
|
|
74
|
-
- Wrong amount.
|
|
75
|
-
|
|
76
|
-
## Payment Safety Rules
|
|
77
|
-
|
|
78
|
-
- Never ask users for full card numbers.
|
|
79
|
-
- Never share service_role keys, API keys, Basic Auth tokens, or gateway tokens.
|
|
80
|
-
- Never manually mark payment captured without provider evidence.
|
|
81
|
-
- Always record provider, reference, amount, currency, and user ID in escalations.
|
|
82
|
-
|
|
1
|
+
# Payments And Payouts
|
|
2
|
+
|
|
3
|
+
Use this guide to support billing setup, shift payment, worker payout, profile promotion, and country-specific payment rails.
|
|
4
|
+
|
|
5
|
+
## Payment Provider By Market
|
|
6
|
+
|
|
7
|
+
- Ghana: Hubtel for checkout, SMS, worker payout, and Ghana-specific flows.
|
|
8
|
+
- Nigeria, Kenya, South Africa: Paystack where configured.
|
|
9
|
+
- India: Razorpay.
|
|
10
|
+
- UK, US, and other markets: Stripe where configured.
|
|
11
|
+
|
|
12
|
+
## Venue Billing
|
|
13
|
+
|
|
14
|
+
Venues may need to connect billing before posting or paying for shifts.
|
|
15
|
+
|
|
16
|
+
Ghana venue billing:
|
|
17
|
+
|
|
18
|
+
- Uses Hubtel gateway `/api/checkout/initiate`.
|
|
19
|
+
- Requires gateway `SUPABASE_SERVICE_ROLE_KEY` to be a real service_role key.
|
|
20
|
+
- Requires Hubtel checkout credentials and account number.
|
|
21
|
+
- Writes checkout/payment state into `payments`.
|
|
22
|
+
|
|
23
|
+
Common errors:
|
|
24
|
+
|
|
25
|
+
- `SUPABASE_SERVICE_ROLE_KEY must have role service_role, not anon`: gateway env uses anon key. Replace with Supabase service role key and restart PM2.
|
|
26
|
+
- `Could not find worker_amount column`: live `payments` schema missing compatibility column. Add column and reload schema.
|
|
27
|
+
- Upstream 500: check gateway PM2 logs and Hubtel response body.
|
|
28
|
+
|
|
29
|
+
## Worker Payout
|
|
30
|
+
|
|
31
|
+
Workers must have valid payout details before payout can complete.
|
|
32
|
+
|
|
33
|
+
Ghana worker payout:
|
|
34
|
+
|
|
35
|
+
- Mobile money or bank details.
|
|
36
|
+
- Phone/account name should be verified where possible.
|
|
37
|
+
- Hubtel sends money or bank transfer through gateway.
|
|
38
|
+
|
|
39
|
+
Other markets:
|
|
40
|
+
|
|
41
|
+
- Paystack recipients/subaccounts for supported African countries.
|
|
42
|
+
- Razorpay fund accounts for India.
|
|
43
|
+
- Stripe Connect for Stripe markets.
|
|
44
|
+
|
|
45
|
+
## Profile Promotion
|
|
46
|
+
|
|
47
|
+
Workers can pay to promote their profile for 7 days.
|
|
48
|
+
|
|
49
|
+
Provider routing:
|
|
50
|
+
|
|
51
|
+
- Ghana: Hubtel checkout.
|
|
52
|
+
- Paystack countries: Paystack checkout.
|
|
53
|
+
- India: Razorpay checkout.
|
|
54
|
+
- Other markets: Stripe checkout.
|
|
55
|
+
|
|
56
|
+
If profile promotion payment succeeds but profile is not promoted:
|
|
57
|
+
|
|
58
|
+
- Check payment verification function for the provider.
|
|
59
|
+
- Check `profile_promotions`.
|
|
60
|
+
- Check `workers.promoted_until`.
|
|
61
|
+
- Escalate if provider captured payment but app did not update.
|
|
62
|
+
|
|
63
|
+
## Refunds And Disputes
|
|
64
|
+
|
|
65
|
+
Do not promise refunds until status is confirmed.
|
|
66
|
+
|
|
67
|
+
Escalate when:
|
|
68
|
+
|
|
69
|
+
- Worker no-show.
|
|
70
|
+
- Venue cancels after worker acceptance.
|
|
71
|
+
- Worker cancels after acceptance.
|
|
72
|
+
- Payment captured but shift canceled.
|
|
73
|
+
- Duplicate charge.
|
|
74
|
+
- Wrong amount.
|
|
75
|
+
|
|
76
|
+
## Payment Safety Rules
|
|
77
|
+
|
|
78
|
+
- Never ask users for full card numbers.
|
|
79
|
+
- Never share service_role keys, API keys, Basic Auth tokens, or gateway tokens.
|
|
80
|
+
- Never manually mark payment captured without provider evidence.
|
|
81
|
+
- Always record provider, reference, amount, currency, and user ID in escalations.
|
|
82
|
+
|
|
@@ -1,95 +1,95 @@
|
|
|
1
|
-
# Shift Lifecycle And Disputes
|
|
2
|
-
|
|
3
|
-
This guide explains how shifts move through the platform and how support should handle attendance, cancellations, no-shows, disputes, and completion.
|
|
4
|
-
|
|
5
|
-
## Shift Statuses
|
|
6
|
-
|
|
7
|
-
Typical statuses:
|
|
8
|
-
|
|
9
|
-
- Draft: venue started but has not posted.
|
|
10
|
-
- Open: workers can apply.
|
|
11
|
-
- Filled: venue accepted a worker.
|
|
12
|
-
- In progress: worker clocked in.
|
|
13
|
-
- Completed: work done and ready for completion/payment processing.
|
|
14
|
-
- Cancelled: shift no longer happening.
|
|
15
|
-
|
|
16
|
-
## Standby Shifts
|
|
17
|
-
|
|
18
|
-
Standby shifts should not display as normal available paid shifts immediately. They should only become relevant when the primary worker does not show or the venue activates standby need.
|
|
19
|
-
|
|
20
|
-
Escalate if:
|
|
21
|
-
|
|
22
|
-
- Worker sees primary and standby shift at the same time.
|
|
23
|
-
- Standby shift shows `0` pay and still allows normal application.
|
|
24
|
-
|
|
25
|
-
## Applications
|
|
26
|
-
|
|
27
|
-
Workers apply for shifts. Venues review applications, match score, trust details, ratings, role history, videos, and certifications.
|
|
28
|
-
|
|
29
|
-
Support should check:
|
|
30
|
-
|
|
31
|
-
- Application status: pending, accepted, declined, withdrawn.
|
|
32
|
-
- Shift owner.
|
|
33
|
-
- Worker identity verification status.
|
|
34
|
-
- Worker role match.
|
|
35
|
-
|
|
36
|
-
## Acceptance
|
|
37
|
-
|
|
38
|
-
When a venue accepts a worker:
|
|
39
|
-
|
|
40
|
-
- Worker should see accepted shift.
|
|
41
|
-
- Worker and venue should be able to message.
|
|
42
|
-
- Ghana workers should receive SMS if phone is valid.
|
|
43
|
-
- Venue should see attendance/arrival state where available.
|
|
44
|
-
|
|
45
|
-
## Clock In And Clock Out
|
|
46
|
-
|
|
47
|
-
Clock-in can happen by:
|
|
48
|
-
|
|
49
|
-
- Venue QR code.
|
|
50
|
-
- Worker manual clock-in where allowed.
|
|
51
|
-
|
|
52
|
-
Expected behavior:
|
|
53
|
-
|
|
54
|
-
- Once clocked in, shift should show active.
|
|
55
|
-
- Returning to the shift page should not ask for clock-in again.
|
|
56
|
-
- Clock-out should close the active time entry.
|
|
57
|
-
|
|
58
|
-
Escalate if duplicate time entries appear or status resets.
|
|
59
|
-
|
|
60
|
-
## No-Shows
|
|
61
|
-
|
|
62
|
-
Each worker no-show should reduce reliability by `-3`.
|
|
63
|
-
|
|
64
|
-
Support should:
|
|
65
|
-
|
|
66
|
-
- Confirm shift date/time.
|
|
67
|
-
- Confirm venue marked no-show.
|
|
68
|
-
- Check messages/arrival evidence.
|
|
69
|
-
- Escalate disputes if worker contests.
|
|
70
|
-
|
|
71
|
-
## Cancellations
|
|
72
|
-
|
|
73
|
-
Worker cancellation can affect reliability and fees. Venue cancellation can trigger refund/worker compensation rules depending on timing.
|
|
74
|
-
|
|
75
|
-
Escalate if:
|
|
76
|
-
|
|
77
|
-
- Worker bypasses cancellation rules.
|
|
78
|
-
- Venue is charged incorrectly.
|
|
79
|
-
- Refund is stuck.
|
|
80
|
-
- Worker says venue canceled but marked worker no-show.
|
|
81
|
-
|
|
82
|
-
## Disputes
|
|
83
|
-
|
|
84
|
-
Collect:
|
|
85
|
-
|
|
86
|
-
- Shift ID or role/date/venue.
|
|
87
|
-
- Worker and venue user IDs if available.
|
|
88
|
-
- Timeline.
|
|
89
|
-
- Messages.
|
|
90
|
-
- Clock-in/out records.
|
|
91
|
-
- Payment records.
|
|
92
|
-
- Screenshots if user has them.
|
|
93
|
-
|
|
94
|
-
Do not decide high-risk disputes without admin review.
|
|
95
|
-
|
|
1
|
+
# Shift Lifecycle And Disputes
|
|
2
|
+
|
|
3
|
+
This guide explains how shifts move through the platform and how support should handle attendance, cancellations, no-shows, disputes, and completion.
|
|
4
|
+
|
|
5
|
+
## Shift Statuses
|
|
6
|
+
|
|
7
|
+
Typical statuses:
|
|
8
|
+
|
|
9
|
+
- Draft: venue started but has not posted.
|
|
10
|
+
- Open: workers can apply.
|
|
11
|
+
- Filled: venue accepted a worker.
|
|
12
|
+
- In progress: worker clocked in.
|
|
13
|
+
- Completed: work done and ready for completion/payment processing.
|
|
14
|
+
- Cancelled: shift no longer happening.
|
|
15
|
+
|
|
16
|
+
## Standby Shifts
|
|
17
|
+
|
|
18
|
+
Standby shifts should not display as normal available paid shifts immediately. They should only become relevant when the primary worker does not show or the venue activates standby need.
|
|
19
|
+
|
|
20
|
+
Escalate if:
|
|
21
|
+
|
|
22
|
+
- Worker sees primary and standby shift at the same time.
|
|
23
|
+
- Standby shift shows `0` pay and still allows normal application.
|
|
24
|
+
|
|
25
|
+
## Applications
|
|
26
|
+
|
|
27
|
+
Workers apply for shifts. Venues review applications, match score, trust details, ratings, role history, videos, and certifications.
|
|
28
|
+
|
|
29
|
+
Support should check:
|
|
30
|
+
|
|
31
|
+
- Application status: pending, accepted, declined, withdrawn.
|
|
32
|
+
- Shift owner.
|
|
33
|
+
- Worker identity verification status.
|
|
34
|
+
- Worker role match.
|
|
35
|
+
|
|
36
|
+
## Acceptance
|
|
37
|
+
|
|
38
|
+
When a venue accepts a worker:
|
|
39
|
+
|
|
40
|
+
- Worker should see accepted shift.
|
|
41
|
+
- Worker and venue should be able to message.
|
|
42
|
+
- Ghana workers should receive SMS if phone is valid.
|
|
43
|
+
- Venue should see attendance/arrival state where available.
|
|
44
|
+
|
|
45
|
+
## Clock In And Clock Out
|
|
46
|
+
|
|
47
|
+
Clock-in can happen by:
|
|
48
|
+
|
|
49
|
+
- Venue QR code.
|
|
50
|
+
- Worker manual clock-in where allowed.
|
|
51
|
+
|
|
52
|
+
Expected behavior:
|
|
53
|
+
|
|
54
|
+
- Once clocked in, shift should show active.
|
|
55
|
+
- Returning to the shift page should not ask for clock-in again.
|
|
56
|
+
- Clock-out should close the active time entry.
|
|
57
|
+
|
|
58
|
+
Escalate if duplicate time entries appear or status resets.
|
|
59
|
+
|
|
60
|
+
## No-Shows
|
|
61
|
+
|
|
62
|
+
Each worker no-show should reduce reliability by `-3`.
|
|
63
|
+
|
|
64
|
+
Support should:
|
|
65
|
+
|
|
66
|
+
- Confirm shift date/time.
|
|
67
|
+
- Confirm venue marked no-show.
|
|
68
|
+
- Check messages/arrival evidence.
|
|
69
|
+
- Escalate disputes if worker contests.
|
|
70
|
+
|
|
71
|
+
## Cancellations
|
|
72
|
+
|
|
73
|
+
Worker cancellation can affect reliability and fees. Venue cancellation can trigger refund/worker compensation rules depending on timing.
|
|
74
|
+
|
|
75
|
+
Escalate if:
|
|
76
|
+
|
|
77
|
+
- Worker bypasses cancellation rules.
|
|
78
|
+
- Venue is charged incorrectly.
|
|
79
|
+
- Refund is stuck.
|
|
80
|
+
- Worker says venue canceled but marked worker no-show.
|
|
81
|
+
|
|
82
|
+
## Disputes
|
|
83
|
+
|
|
84
|
+
Collect:
|
|
85
|
+
|
|
86
|
+
- Shift ID or role/date/venue.
|
|
87
|
+
- Worker and venue user IDs if available.
|
|
88
|
+
- Timeline.
|
|
89
|
+
- Messages.
|
|
90
|
+
- Clock-in/out records.
|
|
91
|
+
- Payment records.
|
|
92
|
+
- Screenshots if user has them.
|
|
93
|
+
|
|
94
|
+
Do not decide high-risk disputes without admin review.
|
|
95
|
+
|
|
@@ -1,40 +1,40 @@
|
|
|
1
|
-
# Support Macros
|
|
2
|
-
|
|
3
|
-
Use these as starting points. Personalize them with the user name, shift, country, or provider.
|
|
4
|
-
|
|
5
|
-
## Worker Cannot See Shifts
|
|
6
|
-
|
|
7
|
-
Hi {{name}}, I can help. ZiloShift shows workers shifts in their saved city and matching roles. Please check that your country, city, town, and roles are saved under Profile. If those are correct and you still cannot see same-city shifts, send us the role and city you expect to see and we will investigate.
|
|
8
|
-
|
|
9
|
-
## Worker Verification Pending
|
|
10
|
-
|
|
11
|
-
Hi {{name}}, your verification may still be syncing. Ghana workers must complete front card, back card, liveness, and name match checks. Non-Ghana workers complete Didit verification. If you completed everything and still see pending, send us the time you verified and the account email so we can review the verification record.
|
|
12
|
-
|
|
13
|
-
## Ghana Card Name Mismatch
|
|
14
|
-
|
|
15
|
-
Hi {{name}}, the name on your ZiloShift account must match the name on your Ghana Card. This protects workers and venues from identity misuse. If your account name was entered incorrectly, we need to escalate it for review instead of changing it directly.
|
|
16
|
-
|
|
17
|
-
## Venue Billing Failed
|
|
18
|
-
|
|
19
|
-
Hi {{name}}, billing setup did not complete. I’ll check the payment provider connection for your country and the exact error returned. Ghana venues use Hubtel checkout, so if the checkout page did not open or returned an upstream error, we may need engineering to review the gateway logs.
|
|
20
|
-
|
|
21
|
-
## Venue Cannot See Applicants
|
|
22
|
-
|
|
23
|
-
Hi {{name}}, I’ll check whether the shift is open, whether workers have applied, and whether the applicant matching finished loading. If the applicant page stays blank for more than a few seconds, we’ll treat it as a loading issue and escalate it.
|
|
24
|
-
|
|
25
|
-
## Worker Accepted For Shift
|
|
26
|
-
|
|
27
|
-
Hi {{name}}, congratulations on being accepted. Please open the shift details and Messages to coordinate with the venue. On the day of the shift, clock in using the venue QR code or the available clock-in button, then clock out when finished.
|
|
28
|
-
|
|
29
|
-
## SMS Campaign Test Failed
|
|
30
|
-
|
|
31
|
-
The test SMS reached the gateway but Hubtel rejected it. Please check the returned details for phone format, sender ID length, SMS account credit, recipient blacklist status, or credential issues.
|
|
32
|
-
|
|
33
|
-
## Payment Delay
|
|
34
|
-
|
|
35
|
-
Hi {{name}}, I can check the payment status. Payout depends on the shift being completed, the venue/payment provider confirming funds, and your payout details being valid. Please send the shift date, venue/company name, and the payout method you selected.
|
|
36
|
-
|
|
37
|
-
## Dispute Received
|
|
38
|
-
|
|
39
|
-
Hi {{name}}, thanks for explaining. We’ll review the shift timeline, messages, clock-in/out records, and payment status before making a decision. Please send any screenshots or details that show what happened.
|
|
40
|
-
|
|
1
|
+
# Support Macros
|
|
2
|
+
|
|
3
|
+
Use these as starting points. Personalize them with the user name, shift, country, or provider.
|
|
4
|
+
|
|
5
|
+
## Worker Cannot See Shifts
|
|
6
|
+
|
|
7
|
+
Hi {{name}}, I can help. ZiloShift shows workers shifts in their saved city and matching roles. Please check that your country, city, town, and roles are saved under Profile. If those are correct and you still cannot see same-city shifts, send us the role and city you expect to see and we will investigate.
|
|
8
|
+
|
|
9
|
+
## Worker Verification Pending
|
|
10
|
+
|
|
11
|
+
Hi {{name}}, your verification may still be syncing. Ghana workers must complete front card, back card, liveness, and name match checks. Non-Ghana workers complete Didit verification. If you completed everything and still see pending, send us the time you verified and the account email so we can review the verification record.
|
|
12
|
+
|
|
13
|
+
## Ghana Card Name Mismatch
|
|
14
|
+
|
|
15
|
+
Hi {{name}}, the name on your ZiloShift account must match the name on your Ghana Card. This protects workers and venues from identity misuse. If your account name was entered incorrectly, we need to escalate it for review instead of changing it directly.
|
|
16
|
+
|
|
17
|
+
## Venue Billing Failed
|
|
18
|
+
|
|
19
|
+
Hi {{name}}, billing setup did not complete. I’ll check the payment provider connection for your country and the exact error returned. Ghana venues use Hubtel checkout, so if the checkout page did not open or returned an upstream error, we may need engineering to review the gateway logs.
|
|
20
|
+
|
|
21
|
+
## Venue Cannot See Applicants
|
|
22
|
+
|
|
23
|
+
Hi {{name}}, I’ll check whether the shift is open, whether workers have applied, and whether the applicant matching finished loading. If the applicant page stays blank for more than a few seconds, we’ll treat it as a loading issue and escalate it.
|
|
24
|
+
|
|
25
|
+
## Worker Accepted For Shift
|
|
26
|
+
|
|
27
|
+
Hi {{name}}, congratulations on being accepted. Please open the shift details and Messages to coordinate with the venue. On the day of the shift, clock in using the venue QR code or the available clock-in button, then clock out when finished.
|
|
28
|
+
|
|
29
|
+
## SMS Campaign Test Failed
|
|
30
|
+
|
|
31
|
+
The test SMS reached the gateway but Hubtel rejected it. Please check the returned details for phone format, sender ID length, SMS account credit, recipient blacklist status, or credential issues.
|
|
32
|
+
|
|
33
|
+
## Payment Delay
|
|
34
|
+
|
|
35
|
+
Hi {{name}}, I can check the payment status. Payout depends on the shift being completed, the venue/payment provider confirming funds, and your payout details being valid. Please send the shift date, venue/company name, and the payout method you selected.
|
|
36
|
+
|
|
37
|
+
## Dispute Received
|
|
38
|
+
|
|
39
|
+
Hi {{name}}, thanks for explaining. We’ll review the shift timeline, messages, clock-in/out records, and payment status before making a decision. Please send any screenshots or details that show what happened.
|
|
40
|
+
|