# JSM sandbox dev Lambda mapping

These directories are isolated from the production Lambda sources:

| AWS Lambda | Repository directory | Event source |
| --- | --- | --- |
| `slack-bot-dev` | `premium-slack-bot-dev/` | Slack dev app |
| `lark-bot-dev` | `premium-lark-bot-dev/` | Lark dev app |
| `CreatJsmIssueHandler-dev` | `create-jsm-issue-handler-dev/` | `SlackJsmQueue-dev` |
| `jsm-orgs-lambda-dev` | `jsm-orgs-lambda-dev/` | EventBridge schedule/manual invocation |

All four functions use the dev-only `jsm-sandbox-dev-dependencies` Lambda Layer.
Its source and lockfile live in `jsm-sandbox-dev-layer/nodejs/`. Function ZIP files
contain business code only; production Layers are not reused or modified.

The bot Lambdas load a deployment-time snapshot of the ST/TCID/TCLS “Submit a request”
fields from their local `sandbox-fields.json`. They do not fetch request metadata
while handling an interactive request. Both bots send selected org, cluster, or
Lake IDs to `SlackJsmQueue-dev`; the handler hydrates the complete synchronized
payloads. ST/TCID use Jira's `/rest/api/3/issue` endpoint, while TCLS uses JSM's
`/rest/servicedeskapi/request` endpoint with its service desk and request type IDs.

Refresh both snapshots before a deployment when a sandbox form changes:

```sh
JIRA_EMAIL=... JIRA_API_TOKEN=... node scripts/sync-jsm-sandbox-fields.js
```

Project mappings, request-type keys, field requirements, option IDs, and the
Slack/Lark channel mappings are static repository configuration so that normal
bot responses do not depend on extra Jira metadata requests. Jira select controls
show up to the first 100 snapshot options, matching the platform control limit.

Runtime guards reject a non-sandbox JSM hostname and a queue URL other than
`SlackJsmQueue-dev`.

The current dev runtime is Node.js 24. Shared dependencies are pinned in the Layer,
including AWS SDK v3 clients; the deprecated monolithic AWS SDK v2 is not used.

Required configuration:

- All: `JSM_SITE=https://tidb-sandbox.atlassian.net`, `JIRA_EMAIL`, `JIRA_API_TOKEN`, `DATABASE_URL`
- Bot Lambdas: `SQS_QUEUE_URL` for `SlackJsmQueue-dev`
- Slack: `SLACK_BOT_TOKEN`, `SLACK_SIGNING_SECRET`
- Lark: `LARK_BOT_APP_ID`, `LARK_BOT_APP_SECRET`
- Handler: Slack and Lark credentials used for reporter lookup and success replies

The dev Slack and Lark channel maps live in each bot's `config.js`. Cloud and
Lake are configured independently under `products.cloud` and `products.lake`;
each product owns its `orgs` and `supportPlan`. A channel with one product opens
that form directly; a channel with both products first asks which request type
to raise. For Cloud, `premium` routes to sandbox ST and `enterprise` routes to
sandbox TCID. Lake currently always routes to sandbox TCLS, leaving room for a
future plan-based project split. For both products, `premium` enables IM/Jira
thread synchronization and `enterprise` disables it.