create-ampless 0.2.0-alpha.8 → 1.0.0-alpha.39

package/dist/templates/_shared/RUNBOOK.ja.md

@@ -0,0 +1,120 @@
+> English: [RUNBOOK.md](./RUNBOOK.md)
+> 
+
+# ランブック
+
+ampless で構築したサイトで、ときどき必要になる運用作業の手順集です。毎日やるわけではないけれど、いざ必要になったときに迷わずに進めるためのものです。
+
+日常的な使い方（コマンド、管理画面、テーマ、プラグイン、デプロイなど）は [README.ja.md](./README.ja.md) を参照してください。
+
+## 目次
+
+- [AppSync API キー（自動更新）](#appsync-api-キー自動更新)
+- [よくある運用](#よくある運用)
+  - [ユーザーの昇格 / 降格](#promote--demote-a-user)
+  - [パスワードリセット（管理者上書き）](#reset-a-users-password-admin-override)
+  - [Post テーブルのバックアップから復元](#restore-from-a-post-table-backup)
+  - [失敗したプラグインイベントを確認する](#inspect-failed-plugin-events)
+- [カスタムドメイン](#custom-domains)
+  - [カスタムドメインを Amplify Hosting に追加する](#adding-a-custom-domain-to-amplify-hosting)
+
+## AppSync API キー（自動更新）
+
+パブリックブログの読み取り（`listPublishedPosts`、`getPublishedPost`、`listPostsByTag`）は AppSync API キーで保護されています。このキーは `amplify_outputs.json` に含まれているため、**公開サイトを訪問した誰もが確認できる**状態にあります。低信頼度のクレデンシャルとして扱ってください。このキーが持つ権限は上記 3 つのカスタムクエリを呼び出すことのみであり、それらのクエリは `status === 'published'` の行しか返しません。
+
+### なぜ API キーなのか（Identity Pool ゲストロールではなく）？
+
+Amplify Gen 2 の `a.handler.custom` リゾルバーは `allow.guest()` や `allow.authenticated('identityPool')` をサポートしておらず、apiKey / userPool / lambda / group / owner のみが使用可能です。v0.1 では簡潔さを優先して API キーを選択しました。パブリック読み取りを Lambda 関数データソース（`a.handler.function`）に移行することは v0.2 の候補です。
+
+### 自動更新 — ローテーション手順は不要
+
+`api-key-renewer` Lambda（`amplify/functions/api-key-renewer/` を参照）は、毎月 1 日の UTC 03:00 に EventBridge スケジュールで起動します。`AppSync.UpdateApiKey` を呼び出して既存キーの `expires` を「現時点 + 364 日」に延長するため、以下が保証されます：
+
+- キー ID は変化しない
+- `amplify_outputs.json` は引き続き有効
+- Next.js アプリの再ビルドは不要
+- 常に約 334 日以上の残有効期限が維持される
+
+手動で確認または実行したい場合：
+
+```bash
+# 現在の有効期限を確認
+aws appsync list-api-keys \
+  --region <amplify_outputs.json の data.aws_region> \
+  --api-id <amplify_outputs.json の data.url から導出した api-id>
+
+# 手動実行（サンドボックスを長期間停止した後など）
+aws lambda invoke \
+  --function-name $(aws lambda list-functions \
+    --query "Functions[?contains(FunctionName,'api-key-renewer')].FunctionName | [0]" \
+    --output text) \
+  /tmp/out.json && cat /tmp/out.json
+```
+
+### キーの漏洩が疑われる場合
+
+有効期限の延長ではなく、キーの値そのものをローテーションする即時対応を行います：
+
+1. `amplify/data/resource.ts` のコメントを編集して CFN 更新を強制する
+2. `npx ampx sandbox`（サンドボックス）または `npx ampx pipeline-deploy ...`（本番）を実行 — Amplify がキーの値を再生成する
+3. Next.js アプリを再デプロイして SSR が新しい `data.api_key` を参照するようにする
+
+## 一般的な操作
+
+### ユーザーのグループ昇格 / 降格
+
+AWS Cognito コンソールから操作します：
+
+1. User Pool → Users → 対象ユーザーを選択
+2. Group memberships → グループに追加 / グループから削除
+3. ユーザーに一度サインアウトしてサインインし直してもらい、新しいクレームを適用させる
+
+グループの種類： `ampless-admin`（フル CRUD + 運用操作）、`ampless-editor`（コンテンツ CRUD）、`ampless-reader`（将来の REST/MCP API 利用者向けに予約済み）。
+
+### ユーザーパスワードのリセット（管理者による上書き）
+
+ロックアウトされており、メールによる復旧が利用できない場合：
+
+```bash
+aws cognito-idp admin-set-user-password \
+  --user-pool-id <amplify_outputs.json の auth.user_pool_id> \
+  --region <リージョン> \
+  --username <メールアドレス> \
+  --password '<新しいパスワード>' --permanent
+```
+
+`/login` ページにはセルフサービスの「パスワードを忘れた場合」フローもあります。
+
+### Post テーブルのバックアップからの復元
+
+DynamoDB のポイントインタイムリカバリ（PITR）は v0.1 の `defineData` では有効になっていません。AWS コンソール → DynamoDB → Tables → `<投稿テーブル名>` → Backups → Edit PITR から手動で有効化してください。有効化後は `aws dynamodb restore-table-to-point-in-time` で新しいテーブルに復元し、その後アイテムをライブテーブルに移行する作業が必要です。
+
+### 失敗したプラグインイベントの確認
+
+処理に失敗したプロセッサー呼び出しは、`amplify/backend.ts` で作成された共有イベント DLQ（`EventsDlq`）に送られます。SQS コンソールまたは `aws sqs receive-message --queue-url <dlq-url> --max-number-of-messages 10` でメッセージを確認してください。v0.1 には自動アラームがないため、定期的な手動確認を推奨します。あるいは `ApproximateNumberOfMessagesVisible` に CloudWatch アラームを設定してください。
+
+## カスタムドメイン
+
+ampless は 1 Amplify デプロイ = 1 サイト。複数サイトを別ドメインで配信したい場合は、サイトごとに Amplify 環境を分けてデプロイしてください。
+
+### Amplify Hosting へのカスタムドメイン追加
+
+バインドしたいドメインごとに以下を実施します：
+
+1. **Amplify Hosting コンソール** → アプリ → **Domain management** → **Add domain** を選択。
+2. 頂点ドメイン（`example.com`）と接続したいサブドメインを入力します。Amplify が ACM 証明書と CloudFront SAN エントリを自動でプロビジョニングします。
+3. DNS を更新：
+   - **Route 53 / Amplify 管理の DNS プロバイダー**：Amplify が CNAME を作成してくれるので、確認するだけです。
+   - **外部 DNS**（Cloudflare、Squarespace など）：Amplify が表示する CNAME / DNS 検証レコードをコピーします。ACM のメール検証もフォールバックとして使用できます。
+4. **Domain activation** が完了するまで待ちます（通常 15〜60 分。証明書の検証が最も時間がかかります）。
+5. `cms.config.ts` の `site.url` を新しい canonical URL に更新し、commit して push します：
+   ```bash
+   git add cms.config.ts && git commit -m "feat: bind docs.example.com"
+   git push   # Amplify Hosting が自動検出します
+   ```
+
+エンドツーエンドで確認：
+
+```bash
+curl -I https://docs.example.com/   # 200 とサイトの HTML
+```

package/dist/templates/_shared/RUNBOOK.md

@@ -1,6 +1,22 @@
+> 日本語版: [RUNBOOK.ja.md](./RUNBOOK.ja.md)
+> 
+
 # Runbook
 
-Operational tasks for an ampless-powered site.
+Step-by-step recipes for occasional operations on an ampless-powered site — the things you don't do every day but want a reliable procedure for when you do.
+
+For day-to-day usage (commands, admin UI tour, themes, plugins, deploying), start with [README.md](./README.md).
+
+## Contents
+
+- [AppSync API key (auto-renewed)](#appsync-api-key-auto-renewed)
+- [Common operations](#common-operations)
+  - [Promote / demote a user](#promote--demote-a-user)
+  - [Reset a user's password (admin override)](#reset-a-users-password-admin-override)
+  - [Restore from a Post-table backup](#restore-from-a-post-table-backup)
+  - [Inspect failed plugin events](#inspect-failed-plugin-events)
+- [Custom domains](#custom-domains)
+  - [Adding a custom domain to Amplify Hosting](#adding-a-custom-domain-to-amplify-hosting)
 
 ## AppSync API key (auto-renewed)
 
@@ -99,49 +115,10 @@ or `aws sqs receive-message --queue-url <dlq-url> --max-number-of-messages 10`.
 There's no automated alarm in v0.1 — periodic manual checks recommended,
 or wire up a CloudWatch alarm on `ApproximateNumberOfMessagesVisible`.
 
-## Multi-site / custom domains
-
-ampless can serve multiple sites from one Amplify Hosting deployment.
-Each site is identified by a `siteId` and bound to one or more
-hostnames via `cms.config.ts`:
-
-```ts
-sites: {
-  blog: {
-    domains: ['blog.example.com', 'www.example.com'],
-    name: 'My Blog',
-    url: 'https://blog.example.com',
-  },
-  docs: {
-    domains: ['docs.example.com'],
-    name: 'Docs',
-    url: 'https://docs.example.com',
-  },
-},
-```
-
-The middleware (`middleware.ts`) maps incoming `Host` to a `siteId` and
-internally rewrites the path to `/_sites/{siteId}/...`. Subdomains and
-fully separate domains are equivalent at the application layer — only
-the AWS-side wiring differs.
-
-### Single domain operation
-
-If `sites` is undefined or has only one entry, ampless runs in
-single-site mode (`siteId='default'`). SSR responses follow each page's
-own caching directives (so you can opt into CloudFront caching with
-`Cache-Control: public, s-maxage=...` per route).
+## Custom domains
 
-### Multi-site mode caveat: SSR caching is force-disabled
-
-When two or more sites are declared, the middleware adds
-`Cache-Control: private, no-store` to every public response. This is
-because Amplify Hosting's CloudFront does not include `Host` in its
-cache key — leaving caching on would let `https://site1/foo` and
-`https://site2/foo` cross-contaminate at the edge. The trade-off is
-that every public read hits Lambda. Lifting it requires moving off
-Amplify Hosting onto a self-managed CloudFront + Open Next stack
-(roadmap: post-v1.0).
+ampless runs one site per Amplify deployment. To serve multiple sites
+on different domains, deploy a separate Amplify environment per site.
 
 ### Adding a custom domain to Amplify Hosting
 
@@ -160,19 +137,15 @@ For each domain you want to bind:
      also works as a fallback.
 4. Wait for the **Domain activation** to finish (typically 15–60
    minutes; certificate validation is the slow step).
-5. Add the new domain to the matching `sites.{id}.domains[]` in
-   `cms.config.ts` and redeploy:
+5. Update `cms.config.ts` so `site.url` reflects the new canonical URL,
+   commit, and push to redeploy:
    ```bash
-   git add cms.config.ts && git commit -m "feat: add docs.example.com"
+   git add cms.config.ts && git commit -m "feat: bind docs.example.com"
    git push   # Amplify Hosting picks it up
    ```
 
 Verify end-to-end:
 
 ```bash
-curl -I https://docs.example.com/                  # 200 with the docs site's HTML
-curl -sI https://docs.example.com/ | grep -i cache # Cache-Control: private, no-store
+curl -I https://docs.example.com/   # 200 with your site's HTML
 ```
-
-If the request returns `404 Site not found` instead, the host is not
-listed in any `sites.*.domains[]` — fix the config and redeploy.

package/dist/templates/_shared/amplify/auth/post-confirmation/resource.ts

@@ -3,4 +3,10 @@ import { defineFunction } from '@aws-amplify/backend'
 export const postConfirmation = defineFunction({
   name: 'post-confirmation',
   entry: './handler.ts',
+  // Auth trigger — assign to the auth nested stack so CFN doesn't
+  // place it in a separate `function` stack that ends up in a
+  // circular dependency loop with auth (which references this
+  // function) and storage/data (which auth happens to reach via
+  // cross-stack refs the function adds).
+  resourceGroupName: 'auth',
 })

package/dist/templates/_shared/amplify/backend.custom.ts

@@ -0,0 +1,41 @@
+import type { AmplessBackend } from '@ampless/backend'
+
+// Custom backend extensions for this project.
+//
+// `amplify/backend.ts` calls `customizeBackend(backend)` right after
+// ampless's baseline wiring. Mutate the passed `backend` instance to
+// add Lambda permissions, attach event sources, register custom CDK
+// constructs, etc.
+//
+// This file is NEVER overwritten by `create-ampless upgrade` —
+// `amplify/backend.ts` is, so keep your customizations here.
+//
+// (Function-export rather than side-effect import on purpose: a
+// top-level `import { backend } from './backend.js'` would create an
+// ESM circular dependency, leaving `backend` in its TDZ at evaluation
+// time. The factory pattern sidesteps that.)
+//
+// Example: granting an existing ampless Lambda extra IAM permissions:
+//
+//   import { Effect, PolicyStatement } from 'aws-cdk-lib/aws-iam'
+//
+//   export function customizeBackend(backend: AmplessBackend): void {
+//     backend.processorTrusted.resources.lambda.addToRolePolicy(
+//       new PolicyStatement({
+//         effect: Effect.ALLOW,
+//         actions: ['ses:SendEmail'],
+//         resources: ['*'],
+//       })
+//     )
+//   }
+//
+// Example: adding your own Lambda function — define it in
+// `amplify/functions/<name>/resource.ts`, import it here, and attach
+// it inside `customizeBackend` via `backend.createStack(...)` or by
+// granting it permissions on existing resources.
+//
+// If you don't need any extensions, leave the body empty.
+
+export function customizeBackend(_backend: AmplessBackend): void {
+  // No-op by default.
+}

package/dist/templates/_shared/amplify/backend.ts

@@ -8,13 +8,17 @@ import { eventDispatcher } from './events/dispatcher/resource.js'
 import { processorTrusted } from './events/processor-trusted/resource.js'
 import { processorUntrusted } from './events/processor-untrusted/resource.js'
 import { apiKeyRenewer } from './functions/api-key-renewer/resource.js'
+import { mcpHandler } from './functions/mcp-handler/resource.js'
+import { userAdmin } from './functions/user-admin/resource.js'
+import { customizeBackend } from './backend.custom.js'
 
 // `defineAmplessBackend` provisions auth, data, storage, the event
 // system (DynamoDB Streams → SQS-trusted / SQS-untrusted → trust_level
 // Lambdas), the AppSync API key renewer, and every IAM / CORS /
 // password policy override. Add custom CDK constructs / IAM policies
-// below by mutating the returned `backend` — `defineAmplessBackend`
-// returns the same object Amplify Gen 2's `defineBackend` does.
+// in `amplify/backend.custom.ts` by mutating the `backend` instance —
+// `defineAmplessBackend` returns the same object Amplify Gen 2's
+// `defineBackend` does.
 const backend = defineAmplessBackend({
   auth,
   data,
@@ -24,6 +28,12 @@ const backend = defineAmplessBackend({
   processorTrusted,
   processorUntrusted,
   apiKeyRenewer,
+  mcpHandler,
+  userAdmin,
 })
 
+// Run user-defined customizations after baseline wiring. `backend.custom.ts`
+// is never overwritten by `create-ampless upgrade`.
+customizeBackend(backend)
+
 export default backend

package/dist/templates/_shared/amplify/data/get-published-post.js

@@ -2,24 +2,21 @@ import { util } from '@aws-appsync/utils'
 
 // AppSync JS resolver: returns a single published post by slug.
 //
-// Reads the `bySiteIdSlug` GSI: PK = `${siteId}#${slug}`. A given
-// (site, slug) tuple identifies at most one row, so this is an O(1)
-// PK Query — no scan, no filter, no per-partition limit issues.
+// Reads the `bySlug` GSI: PK = slug. A slug identifies at most one row
+// (uniqueness enforced at the admin form level), so this is an O(1) PK
+// Query — no scan, no filter, no per-partition limit issues.
 //
-// Drafts are dropped in the response handler. The admin form
-// enforces a unique slug per site at the application layer, but if
-// somehow draft + published share a slug we prefer the published row.
+// Drafts are dropped in the response handler. If draft + published
+// somehow share a slug we prefer the published row.
 export function request(ctx) {
-  const siteId = ctx.args.siteId ?? 'default'
   const slug = ctx.args.slug
-  const partition = `${siteId}#${slug}`
   return {
     operation: 'Query',
-    index: 'bySiteIdSlug',
+    index: 'bySlug',
     query: {
-      expression: '#siteIdSlug = :siteIdSlug',
-      expressionNames: { '#siteIdSlug': 'siteIdSlug' },
-      expressionValues: util.dynamodb.toMapValues({ ':siteIdSlug': partition }),
+      expression: '#slug = :slug',
+      expressionNames: { '#slug': 'slug' },
+      expressionValues: util.dynamodb.toMapValues({ ':slug': slug }),
     },
     limit: 5,
   }

package/dist/templates/_shared/amplify/data/list-posts-by-tag.js

@@ -2,23 +2,21 @@ import { util } from '@aws-appsync/utils'
 
 // AppSync JS resolver: list published posts for a given tag, newest first.
 // Reads the denormalized PostTag table where:
-//   PK = `${siteId}#${tag}`
+//   PK = tag
 //   SK = `${publishedAt}#${postId}` (so descending SK = newest first)
 //
 // Authorization is enforced by AppSync; the resolver itself only encodes
-// the tag/site partition condition. Drafts never appear here because the
+// the tag partition condition. Drafts never appear here because the
 // admin client only writes PostTag rows for posts whose status is
 // 'published'.
 export function request(ctx) {
-  const { siteId = 'default', tag, limit, nextToken } = ctx.args
+  const { tag, limit, nextToken } = ctx.args
   return {
     operation: 'Query',
     query: {
-      expression: '#siteIdTag = :siteIdTag',
-      expressionNames: { '#siteIdTag': 'siteIdTag' },
-      expressionValues: util.dynamodb.toMapValues({
-        ':siteIdTag': `${siteId}#${tag}`,
-      }),
+      expression: '#tag = :tag',
+      expressionNames: { '#tag': 'tag' },
+      expressionValues: util.dynamodb.toMapValues({ ':tag': tag }),
     },
     scanIndexForward: false, // newest first (SK descends)
     limit: limit ?? 20,
@@ -33,7 +31,6 @@ export function response(ctx) {
   // PublicPost shape `listPublishedPosts` returns; the detail view should
   // call `getPublishedPost(slug)` for the full body.
   const items = (ctx.result.items ?? []).map((row) => ({
-    siteId: row.siteId,
     postId: row.postId,
     slug: row.slug,
     title: row.title,

package/dist/templates/_shared/amplify/data/list-published-posts.js

@@ -1,23 +1,22 @@
 import { util } from '@aws-appsync/utils'
 
-// AppSync JS resolver: list a site's published posts, newest first.
+// AppSync JS resolver: list published posts, newest first.
 //
-// Reads the `bySiteIdStatus` GSI:
-//   PK = `${siteId}#${status}`   (denormalized field set by writers)
+// Reads the `byStatus` GSI:
+//   PK = status   (denormalized field set by writers)
 //   SK = publishedAt
-// so a single Query reads only one site's published partition. Drafts
-// never appear because the PK condition pins status='published'.
+// so a single Query reads only the `published` partition. Drafts never
+// appear because the PK condition pins status='published'.
 //
 // Date-range filtering (`from`, `to`) is pushed into the SK condition,
 // so DynamoDB only reads the matching range. `nextToken` paginates
 // without re-issuing a fresh query.
 export function request(ctx) {
-  const { siteId = 'default', from, to, limit, nextToken } = ctx.args
+  const { from, to, limit, nextToken } = ctx.args
 
-  const partition = `${siteId}#published`
-  let keyExpression = '#siteIdStatus = :siteIdStatus'
-  const expressionNames = { '#siteIdStatus': 'siteIdStatus' }
-  const expressionValueMap = { ':siteIdStatus': partition }
+  let keyExpression = '#status = :status'
+  const expressionNames = { '#status': 'status' }
+  const expressionValueMap = { ':status': 'published' }
 
   if (from && to) {
     keyExpression += ' AND #publishedAt BETWEEN :from AND :to'
@@ -36,7 +35,7 @@ export function request(ctx) {
 
   return {
     operation: 'Query',
-    index: 'bySiteIdStatus',
+    index: 'byStatus',
     query: {
       expression: keyExpression,
       expressionNames,

package/dist/templates/_shared/amplify/data/resource.custom.ts

@@ -0,0 +1,32 @@
+// Custom data schema models for this project.
+//
+// `amplify/data/resource.ts` calls `customSchemaModels(a)` and spreads
+// the result alongside ampless's built-in models in the same
+// `a.schema({...})` call, which is the only way Amplify Gen 2's
+// `ClientSchema<typeof schema>` inference picks up extra models.
+//
+// This file is NEVER overwritten by `create-ampless upgrade` —
+// `amplify/data/resource.ts` is, so keep your custom models here.
+//
+// Example:
+//
+//   export function customSchemaModels(a: any) {
+//     return {
+//       Bookmark: a
+//         .model({
+//           bookmarkId: a.id().required(),
+//           url: a.string().required(),
+//           title: a.string(),
+//         })
+//         .identifier(['bookmarkId'])
+//         .authorization((allow: any) => [allow.groups(['ampless-admin', 'ampless-editor'])]),
+//     }
+//   }
+//
+// `a` is the Amplify Gen 2 schema builder; see Amplify Data docs for
+// the full DSL. Return an empty object if no customizations are needed.
+
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+export function customSchemaModels(_a: any): Record<string, unknown> {
+  return {}
+}

package/dist/templates/_shared/amplify/data/resource.ts

@@ -1,7 +1,14 @@
 import { fileURLToPath } from 'node:url'
 import { dirname, resolve } from 'node:path'
 import { a, defineData, type ClientSchema } from '@aws-amplify/backend'
-import { amplessSchemaModels, defaultAuthorizationModes } from '@ampless/backend'
+import {
+  amplessSchemaModels,
+  amplessSchemaAuthorization,
+  defaultAuthorizationModes,
+} from '@ampless/backend'
+import { userAdmin } from '../functions/user-admin/resource.js'
+import { mcpHandler } from '../functions/mcp-handler/resource.js'
+import { customSchemaModels } from './resource.custom.js'
 
 // AppSync's `a.handler.custom({ entry })` paths are resolved by CDK
 // relative to the file that called `a.handler.custom`. When the call
@@ -16,24 +23,30 @@ const __dirname = dirname(fileURLToPath(import.meta.url))
 // KvStore) plus the three public-read custom queries
 // (listPublishedPosts / getPublishedPost / listPostsByTag).
 //
-// Add project-specific models alongside the spread:
-//
-//   const schema = a.schema({
-//     ...amplessSchemaModels(a, { resolverPaths }),
-//     MyCustomModel: a
-//       .model({ siteId: a.string().required(), foo: a.string() })
-//       .identifier(['siteId', 'foo'])
-//       .authorization((allow) => [allow.groups(['ampless-admin'])]),
-//   })
+// Add project-specific models in `amplify/data/resource.custom.ts` —
+// that file is never overwritten by `create-ampless upgrade`.
 const resolverPaths = {
   listPublishedPosts: resolve(__dirname, 'list-published-posts.js'),
   getPublishedPost: resolve(__dirname, 'get-published-post.js'),
   listPostsByTag: resolve(__dirname, 'list-posts-by-tag.js'),
 }
 
-const schema = a.schema({
-  ...amplessSchemaModels(a, { resolverPaths }),
-})
+const schema = a
+  .schema({
+    ...amplessSchemaModels(a, {
+      resolverPaths,
+      userAdminFunction: userAdmin,
+    }),
+    ...customSchemaModels(a),
+  })
+  // Schema-level `.authorization()` is the only place resource auth is
+  // honoured in `@aws-amplify/data-schema` — model-level callbacks have
+  // `resource` destructured out of `allow`. The helper returns an empty
+  // array when no Lambda refs are supplied, so the schema stays
+  // unaffected if MCP is later removed.
+  .authorization((allow) => amplessSchemaAuthorization(allow, {
+    mcpHandlerFunction: mcpHandler,
+  }))
 
 export type Schema = ClientSchema<typeof schema>
 export const data = defineData({

package/dist/templates/_shared/amplify/events/processor-untrusted/resource.ts

@@ -6,4 +6,8 @@ export const processorUntrusted = defineFunction({
   // Untrusted plugins do pure JS work; modest memory.
   memoryMB: 256,
   timeoutSeconds: 30,
+  // Pin to the data stack so all event-system Lambdas live together
+  // (dispatcher / processor-trusted are also `data`) and the function
+  // stack doesn't bridge data ↔ storage ↔ auth in a CFN cycle.
+  resourceGroupName: 'data',
 })

package/dist/templates/_shared/amplify/functions/mcp-handler/handler.ts

@@ -0,0 +1 @@
+export { handler } from '@ampless/backend/functions/mcp-handler'

package/dist/templates/_shared/amplify/functions/mcp-handler/resource.ts

@@ -0,0 +1,11 @@
+import { defineFunction } from '@aws-amplify/backend'
+
+export const mcpHandler = defineFunction({
+  name: 'mcp-handler',
+  entry: './handler.ts',
+  // Co-locate with the data stack so the function has the KvStore
+  // table ARN available without cross-stack references at synth time.
+  resourceGroupName: 'data',
+  memoryMB: 512,
+  timeoutSeconds: 30,
+})

package/dist/templates/_shared/amplify/functions/user-admin/handler.ts

@@ -0,0 +1,4 @@
+// Re-exported from @ampless/backend so the package can ship Lambda
+// handler updates via `npm update`. Amplify's esbuild follows this
+// import and bundles the real handler into the Lambda artifact.
+export { handler } from '@ampless/backend/auth/user-admin'

package/dist/templates/_shared/amplify/functions/user-admin/resource.ts

@@ -0,0 +1,12 @@
+import { defineFunction } from '@aws-amplify/backend'
+
+// `resourceGroupName: 'data'` co-locates this Lambda with the AppSync
+// stack. Required because ampless wires userAdmin as a custom GraphQL
+// resolver (data → function) while api-key-renewer reads graphqlApi
+// (function → data); leaving userAdmin in the default `function` stack
+// turns those two arrows into a CloudFormation circular dependency.
+export const userAdmin = defineFunction({
+  name: 'user-admin',
+  entry: './handler.ts',
+  resourceGroupName: 'data',
+})

package/dist/templates/_shared/app/(admin)/admin/mcp-tokens/page.tsx

@@ -0,0 +1,5 @@
+import { admin } from '@/lib/admin'
+import { createMcpTokensPage } from '@ampless/admin/pages'
+
+export const dynamic = 'force-dynamic'
+export default createMcpTokensPage(admin)

package/dist/templates/_shared/app/(admin)/admin/users/page.tsx

@@ -0,0 +1,5 @@
+import { admin } from '@/lib/admin'
+import { createUsersListPage } from '@ampless/admin/pages'
+
+export const dynamic = 'force-dynamic'
+export default createUsersListPage(admin)