# JSM production v2

For the current implementation and deployment handoff, read
[`HANDOFF.md`](./HANDOFF.md) first.

Production has migrated to v2. The original non-v2 Bot, issue worker, org
synchronizer, and queue are deprecated; all ongoing changes and deployments
must use this directory and the matching `*-v2` AWS resources.

This directory contains the complete, isolated production v2 source tree. Each
AWS Lambda has its own source directory and package boundary. Production v2 no
longer builds from any `*-dev` directory.

## Layout

```text
jsm-production-v2/
├── slack-bot/              # Lambda: slack-bot-v2
├── lark-bot/               # Lambda: lark-support-bot-v2
├── create-issue-handler/   # Lambda: CreateJsmIssueHandler-v2
├── org-sync/               # Lambda: jsm-orgs-lambda-v2
├── shared/                 # frozen Slack/Lark channel configuration
├── layer/nodejs/           # source for the shared dependency Layer
├── infrastructure/         # resource names, schema and deployment state
└── scripts/                # reproducible artifact builder
```

The Lambda handlers produced by the build are:

| Lambda | Handler |
| --- | --- |
| `slack-bot-v2` | `slack-bot/app.handler` |
| `lark-support-bot-v2` | `lark-bot/app.handler` |
| `CreateJsmIssueHandler-v2` | `create-issue-handler/index.handler` |
| `jsm-orgs-lambda-v2` | `org-sync/index.handler` |

Slack and Lark each receive only their own source directory plus `shared/`.
The issue worker and org synchronizer receive only their own source directory.
The four Lambda archives therefore remain independent even though Slack and
Lark share one frozen channel snapshot.

## Dependency Layer

`layer/nodejs/package.json` and its lock file are the authoritative Layer
definition. The lock pins the exact dependency versions used by the already
created `jsm-production-v2-dependencies` Layer. `node_modules` is generated only
while building and is not committed.

Build all four Lambda archives and the Layer archive with:

```bash
npm run build --prefix jsm-production-v2
```

Artifacts are written under the ignored `jsm-production-v2/dist/` directory.
Building the Layer runs `npm ci`, so it requires access to the npm registry.

## Configuration and safety

`shared/channel-config.json` started as a migration snapshot of the original
production Cloud channel mappings and now is the authoritative v2 runtime
configuration. Runtime configs filter out disabled channels. All migrated
production channels and the approved test channels are currently enabled. The
channel snapshot also contains the approved Enterprise Lake group
configuration.

The ST and TCID entries in `slack-bot/request-fields.json` and
`lark-bot/request-fields.json` use the current formal project, issue type,
request type, Environment, Severity, Components, and Versions configuration.
Their production Cloud fields are `customfield_17125` for Org and
`customfield_17124` for Cluster. Customer links point to ST portal 9, TCID
portal 6, and TCLID portal 4219.

ST and TCID create requests through their formal `Submit a request` request
types: ST uses portal 9/request type `2164`, and TCID uses portal 6/request type
`30`. The existing field snapshots are intentionally unchanged until the
formal forms complete their field migration.

The `TCLID` configuration points to the formal TCLID project and its
`Submit a request` request type `4398`. Its production fields are
`customfield_17125` for Org and `customfield_17123` for Lake.

Runtime secrets and endpoints remain in Lambda configuration or the approved
secret store and must not be committed:

- Common: `DATABASE_URL`, `JSM_SITE`, `JIRA_EMAIL`, `JIRA_API_TOKEN`
- Bot Lambdas: `SQS_QUEUE_URL`
- Slack: `SLACK_BOT_TOKEN`, `SLACK_SIGNING_SECRET`
- Lark: `LARK_BOT_APP_ID`, `LARK_BOT_APP_SECRET`, `LARK_BOT_UNION_ID`
- Org sync: `JSM_SYNCER_BASE_URL`, `JSM_SYNCER_API_TOKEN`

The production JSM host and v2 queue names are also checked by the runtime.

## Infrastructure state

Resource names and conservative defaults live in
`infrastructure/resources.js`. Database DDL is in
`infrastructure/schema.sql`. The currently deployed but inactive AWS resource
inventory is recorded in `infrastructure/deployment-state.md`.

The v2 stack reuses the existing production `messages`, `ticket_thread`, and
`user_openid_email_mapping` tables. The org, cluster, and Lake snapshot tables
are new and do not replace the legacy Assets tables.

The three interactive v2 Lambdas have no reserved concurrency, matching their
production counterparts. The SQS event source mapping is enabled for the
isolated v2 queue. Scheduler `jsm-orgs-v2-daily-sync` is enabled and invokes
`jsm-orgs-lambda-v2` every 24 hours in the `Asia/Shanghai` timezone.

## Before activation

1. Refresh and review the production ST, TCID and TCLID field snapshots.
2. Apply and validate `infrastructure/schema.sql`.
3. Validate the scheduled org synchronization and snapshot counts.
4. Review all enabled channels in `shared/channel-config.json`.
5. Build and deploy a new immutable Layer version and the four Lambda packages.
6. Update each Lambda handler to the path listed above while it remains disabled.
7. Invoke each Lambda directly with controlled test events.
8. Enable the SQS mapping and one bot callback at a time.