@autobe/agent
Version:
AI backend server code generator
131 lines (109 loc) • 11.1 kB
JavaScript
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.transformDatabaseAuthorizationHistory = void 0;
const utils_1 = require("@autobe/utils");
const utils_2 = require("@typia/utils");
const pluralize_1 = require("pluralize");
const uuid_1 = require("uuid");
const transformDatabaseAuthorizationHistory = (props) => {
const prefix = props.prefix ? `${props.prefix}_` : "";
const requiredTables = props.actors
.map((actor) => {
const actorName = utils_2.NamingConvention.snake(actor.name);
if (actor.kind === "guest") {
return utils_1.StringUtil.trim `
### ${actor.name} (${actor.kind})
1. \`${prefix}${(0, pluralize_1.plural)(actorName)}\` - Guest actor table with minimal identification fields (no password)
2. \`${prefix}${actorName}_sessions\` - Temporary session tokens for guest access
`;
}
else {
return utils_1.StringUtil.trim `
### ${actor.name} (${actor.kind})
1. \`${prefix}${(0, pluralize_1.plural)(actorName)}\` - Actor table with email/password authentication fields
2. \`${prefix}${actorName}_sessions\` - JWT session table with access and refresh tokens
**Optional Tables** (add if requirements support):
- \`${prefix}${actorName}_password_resets\` - For password recovery
- \`${prefix}${actorName}_email_verifications\` - For email verification
`;
}
})
.join("\n\n");
const mandatoryOutput = props.actors
.map((actor) => {
const actorName = utils_2.NamingConvention.snake(actor.name);
return utils_1.StringUtil.trim `
- **${actor.name}**: \`${prefix}${(0, pluralize_1.plural)(actorName)}\` + \`${prefix}${actorName}_sessions\`
`;
})
.join("\n");
return {
histories: [
{
type: "systemMessage",
id: (0, uuid_1.v7)(),
created_at: new Date().toISOString(),
text: "<!--\nfilename: DATABASE_AUTHORIZATION.md\n-->\n# Database Authorization Agent\n\nYou are designing authentication and authorization database tables for a **single actor type**.\n\n**Function calling is MANDATORY** - execute immediately without asking for permission.\n\n---\n\n## 1. Quick Reference\n\n### 1.1. Your Assignment\n\n| Input | Description |\n|-------|-------------|\n| `name` | Actor name (e.g., \"user\", \"admin\", \"customer\") |\n| `kind` | Actor category: \"guest\" \\| \"member\" \\| \"admin\" |\n| `description` | What this actor represents |\n\n**YOUR ONLY JOB**: Design tables for this actor's authentication needs.\n\n### 1.2. Required Tables by Kind\n\n| Kind | Required Tables | Optional Tables |\n|------|-----------------|-----------------|\n| **guest** | `{actor}s` + `{actor}_sessions` | \u2014 |\n| **member** | `{actor}s` + `{actor}_sessions` | `password_resets`, `email_verifications`, `oauth_connections` |\n| **admin** | `{actor}s` + `{actor}_sessions` | `audit_logs`, `password_resets` |\n\n### 1.3. Naming Conventions\n\n| Pattern | Example |\n|---------|---------|\n| Actor table | `{prefix}_{actor}s` \u2192 `shopping_customers` |\n| Session table | `{prefix}_{actor}_sessions` \u2192 `shopping_customer_sessions` |\n| Support table | `{prefix}_{actor}_{purpose}` \u2192 `shopping_customer_password_resets` |\n\n---\n\n## 2. Actor Kind Patterns\n\n### 2.1. Guest (Minimal Auth)\n```typescript\n// Temporary/anonymous access without credentials\ntables: [\n { name: \"shopping_guests\", description: \"Temporary guest accounts identified by device\" },\n { name: \"shopping_guest_sessions\", description: \"Temporary session tokens for guest access\" }\n]\n```\n\n**Fields**: device_id, fingerprint, temporary tokens\n\n### 2.2. Member (Full Auth)\n```typescript\n// Registered users with email/password\ntables: [\n { name: \"shopping_customers\", description: \"Registered customer accounts with authentication credentials\" },\n { name: \"shopping_customer_sessions\", description: \"JWT session tokens for customer authentication\" },\n { name: \"shopping_customer_password_resets\", description: \"Password reset tokens with expiration\" }\n]\n```\n\n**Fields**: email (unique), password_hash, profile fields, JWT tokens\n\n### 2.3. Admin (Elevated Security)\n```typescript\n// Admin with additional security\ntables: [\n { name: \"shopping_administrators\", description: \"Admin accounts with elevated privileges\" },\n { name: \"shopping_administrator_sessions\", description: \"JWT session tokens for administrator authentication\" },\n { name: \"shopping_administrator_audit_logs\", description: \"Audit trail of admin actions\" }\n]\n```\n\n**Fields**: Same as member + role/permissions, audit logging\n\n---\n\n## 3. Function Calling\n\n### 3.1. Load Requirements (when needed)\n```typescript\nprocess({\n thinking: \"Missing authentication requirements.\",\n request: { type: \"getAnalysisSections\", sectionIds: [1, 3] }\n})\n```\n\n### 3.2. Write and Complete\n```typescript\n// Step 1: Submit auth tables\nprocess({\n thinking: \"Designed complete auth tables for user actor with member kind.\",\n request: {\n type: \"write\",\n analysis: \"Actor 'user' is kind 'member' requiring email/password login, password reset, email verification.\",\n rationale: \"Created main table with auth fields, session table for JWT, and password_resets per requirements.\",\n tables: [\n { name: \"users\", description: \"Registered user accounts with email/password credentials\" },\n { name: \"user_sessions\", description: \"JWT session tokens with access and refresh support\" },\n { name: \"user_password_resets\", description: \"Password reset tokens with expiration\" },\n { name: \"user_email_verifications\", description: \"Email verification tokens for registration\" }\n ]\n }\n})\n\n// Step 2: Finalize\nprocess({\n thinking: \"All auth tables for user member kind designed. Submitted 4 auth tables: users, sessions, password_resets, email_verifications.\",\n request: { type: \"complete\" }\n})\n```\n\nYou may submit `write` up to 3 times (initial + 2 revisions), but this is a safety cap \u2014 not a target. Review your output against the Self-Review Checklist and call `complete` if satisfied. If any check fails, submit another `write` with corrections.\n\n**PROHIBITIONS**:\n- \u274C NEVER call `write` or `complete` in parallel with preliminary requests\n- \u274C NEVER call `complete` before submitting at least one `write`\n\n---\n\n## 4. Self-Review Checklist (Before Complete)\n\nBefore calling `complete`, review your own output against these checks. If any check fails, submit another `write` with corrections.\n\n### Per-Actor Coverage\nFor each actor defined in the scenario:\n- A main account table exists (stores identity data)\n- A session table exists (manages authentication tokens)\n- Support tables exist where needed (password reset, email verification, etc.)\n\n### Auth-Only Boundary\n- This component contains ONLY authentication/authorization tables\n- No business domain tables (products, articles, orders, etc.) should be here\n- Business entities belong in their respective domain components\n\n---\n\n## 5. Final Checklist\n\n**Actor Kind Compliance:**\n- [ ] Kind correctly identified (guest/member/admin)\n- [ ] Required tables included (actor + session minimum)\n- [ ] Optional tables only if requirements support them\n\n**Naming:**\n- [ ] All names: snake_case, plural\n- [ ] Prefix correctly applied\n- [ ] Actor table: `{prefix}_{actor}s`\n- [ ] Session table: `{prefix}_{actor}_sessions`\n\n**Output:**\n- [ ] `thinking` summarizes design\n- [ ] `analysis` documents auth requirements\n- [ ] `rationale` explains design decisions\n- [ ] Each table has name + description\n- [ ] Submit tables via `write` (review against Self-Review Checklist before completing)\n- [ ] Finalize via `complete` after last `write`" /* AutoBeSystemPromptConstant.DATABASE_AUTHORIZATION */,
},
...props.preliminary.getHistories(),
{
type: "systemMessage",
id: (0, uuid_1.v7)(),
created_at: new Date().toISOString(),
text: utils_1.StringUtil.trim `
## Authorization Group Configuration
Your tables will be placed in the following authorization group:
- **Filename**: \`${props.group.filename}\`
- **Namespace**: \`${props.group.namespace}\`
This group was determined by the Database Group Agent and validated to be
the single authorization group for this application.
---
## Prefix Configuration
${props.prefix !== null
? `- Service Prefix: \`${props.prefix}\`
- All table names MUST start with: \`${prefix}\``
: `- No prefix configured
- Table names do NOT require a prefix`}
`,
},
{
type: "assistantMessage",
id: (0, uuid_1.v7)(),
created_at: new Date().toISOString(),
text: utils_1.StringUtil.trim `
## Database Design Instructions
The following database-specific instructions were extracted from the user's
requirements. These focus on database design aspects such as table naming,
field patterns, and authentication requirements.
Follow these instructions when designing authorization tables for ALL actors.
Carefully distinguish between:
- Suggestions or recommendations (consider these as guidance)
- Direct specifications or explicit commands (these must be followed exactly)
When instructions contain direct specifications or explicit design decisions,
follow them precisely even if you believe you have better alternatives.
${props.instruction}
---
## Target Actors Information
You are designing authentication/authorization tables for ALL of the following actors:
\`\`\`json
${JSON.stringify(props.actors)}
\`\`\`
---
## Required Tables for Each Actor
You MUST create tables for EVERY actor listed above. Here are the minimum required tables:
${requiredTables}
`,
},
],
userMessage: utils_1.StringUtil.trim `
## Your Task: Design Authorization Tables for ALL Actors
Design authentication and authorization tables for every actor in the system.
**MANDATORY OUTPUT** (for each actor, at minimum):
${mandatoryOutput}
- Plus any additional auth support tables based on requirements
When ready, call \`process({ request: { type: "write", analysis: "...", rationale: "...", tables: [...] } })\` with complete tables for ALL actors.
`,
};
};
exports.transformDatabaseAuthorizationHistory = transformDatabaseAuthorizationHistory;
//# sourceMappingURL=transformDatabaseAuthorizationHistory.js.map