MinStack ভিত্তিক Business Automation

Platform
Database-Aware AI Agent Prompt Guide
Laravel + MySQL + Blade + Bootstrap 5

আপনার existing admin, permission, user, wallet, deposit, withdrawal ও transaction system reuse
করে
step-by-step full project build করার জন্য প্রস্তুত prompt sequence।

Source database audited: [Link] | 32 existing tables

1. Database Audit Summary
শুধু database dump পাওয়া গেছে; application source code, Laravel version, routes, models ও packages
পাওয়া যায়নি। তাই এই guide database structure-এর উপর grounded, আর AI agent-কে প্রথম phase-এ source-
code audit বাধ্যতামূলক করা হয়েছে।

Existing area Tables / fields found Project decision

admins.role_id, permissions, roles, Existing admin authentication ও
Admin & permission
permission_roles permission UI reuse করতে হবে।
parent_id=0 owner; staff-এর
User tenancy hint users.parent_id, users.role_id parent_id=owner user id হিসেবে
tenant relation ব্যবহার করা হবে।
Existing balance ও transaction ledger
Wallet & ledger [Link], transactions core billing/credit system হিসেবে
reuse হবে।
Existing deposit/gateway flow plan
deposits, gateways,
Payments purchase ও wallet top-up-এ reuse
gateway_currencies
হবে।
Core automation MVP-তে প্রয়োজন
Withdrawal withdrawals, withdraw_methods
নেই; existing feature intact থাকবে।
notification_templates, Existing global notification engine
Notifications notification_logs, reuse; tenant SMTP addon আলাদা
general_settings.mail_config optional integration হবে।
support_tickets, support_messages, Existing support module unchanged
Support
support_attachments থাকবে।
এটি marketing/plugin settings table;
addon runtime manager হিসেবে
Plugins plugins
blindly reuse করা হবে না। নতু ন
modules tables থাকবে।

2. Final Architecture Decisions

 `admins` table Super Admin panel-এর জন্য অপরিবর্তি ত থাকবে। নতু ন admin auth বানানো যাবে না।
 `users` table tenant owner ও staff উভয়কে manage করবে। আলাদা tenants/businesses master table তৈরি
হবে না।
 Owner user: `parent_id = 0`; Staff user: `parent_id = owner_user_id`। Effective tenant ID owner-এর
ক্ষেত্রে নিজের id, staff-এর ক্ষেত্রে parent_id।
 Existing `roles` ও `permission_roles` user permission-এর জন্য reuse হবে; agent source code audit করে
relation verify করবে।
 Existing `balance`, `transactions`, `deposits`, `gateways` subscription/credit purchase-এর financial
backbone হবে।
 Future addon support-এর জন্য core-safe module registry, dependency, version ও per-user enablement
tables যোগ হবে।
 Every new business table-এ `tenant_id` থাকবে, যার মান effective owner user id।
 Frontend Blade + Bootstrap 5 + normal HTML/CSS/JavaScript/jQuery; workflow canvas-এর জন্য
Drawflow ব্যবহার করা যাবে।
3. New Core Tables Required
Table group Purpose / key fields
tenant_id unique, business_name, email, phone, logo, timezone,
tenant_profiles
currency, country, address, settings
plans / plan_features SaaS/self-hosted feature and usage limits
subscriptions / usage_counters user subscription, expiry, monthly usage
modules / module_versions / module_dependencies addon registry and compatibility
user_modules / module_installation_logs owner-wise addon activation and audit
contacts / tags / contact_tag / contact_notes / contact_activities basic CRM data
tasks assignable task automation
workflows / workflow_versions / workflow_nodes /
visual workflow definitions
workflow_edges
workflow_runs / workflow_run_nodes / workflow_run_logs /
runtime and observability
workflow_wait_states
approval_requests / approval_actions human approval nodes
integrations / integration_credentials / integration_logs tenant-owned integrations
api_keys / api_request_logs / idempotency_keys public REST API
incoming_webhook_endpoints / incoming_webhook_requests generic incoming events
outgoing_http_deliveries outgoing request logs and retry
notification_deliveries workflow communication delivery logs
4. How to Use These Prompts
1. একবার Master Context Prompt দিন।
2. তারপর Phase 0 Audit Prompt দিন। Agent audit report না দেওয়া পর্যন্ত migration/code লিখতে দেবেন না।
3. প্রতিটি phase শেষে application manually check করুন এবং provided Audit Prompt দিন।
4. সব critical/high issue fix হলে পরবর্তী phase prompt দিন।
5. Error হলে শুধু Error Fix Prompt দিন; next feature build করতে নিষেধ করুন।
6. প্রতিটি phase আলাদা Git branch/commit-এ রাখুন।

5. Master Context Prompt

Copy Prompt - Master Context
You are a senior Laravel architect working inside an EXISTING Laravel project kit.

The supplied database is MinStack and already contains 32 tables. You MUST preserve and reuse existing features instead
of rebuilding them.

EXISTING DATABASE FACTS

- Admin system: admins table with role_id.
- Permission system: permissions, roles, permission_roles.
- Users: users table with parent_id, role_id, balance, status, KYC and verification fields.
- Finance: transactions, deposits, withdrawals, gateways, gateway_currencies and withdraw_methods.
- Notifications: notification_templates, notification_logs and general_settings mail/SMS config.
- Existing support, frontend CMS, menus, pages, plugins and language systems.

NON-NEGOTIABLE REUSE RULES

1. Do not create another admin authentication system.
2. Do not replace existing admin roles or permission implementation.
3. Do not create another users table.
4. Do not create a tenants or businesses master table.
5. Do not create a duplicate wallet, deposit, transaction, gateway, notification or support system.
6. Never rename or drop existing columns without a written compatibility plan and my explicit approval.
7. Existing functionality must continue working.

USER-BASED TENANCY
- A business owner is a user with parent_id = 0.
- A staff user has parent_id = the owner user's id.
- Effective tenant ID:
- owner => [Link]
- staff => user.parent_id
- Every new tenant-owned table must include tenant_id referencing the effective owner user id.
- Super Admin uses the existing admins guard and can inspect all tenants.
- Create TenantContext and ResolveTenant middleware after auditing the existing auth guards.
- Never trust tenant_id from request input.

PRODUCT
Build a no-code Business Automation Platform:
Trigger -> Condition -> Branch -> Delay -> Approval -> Action -> Log.
Examples:
- New contact -> assign staff -> create task -> send email.
- Incoming webhook -> condition -> outgoing API call -> Slack alert.
- WooCommerce order -> create task -> WhatsApp template -> log result.

TECH STACK
- Existing Laravel version and conventions
- MySQL
- Blade
- Bootstrap 5
- Existing jQuery/JavaScript conventions
- Drawflow is allowed for drag-and-drop workflow canvas
- Laravel Queue and Scheduler
- Redis/Horizon only if the project/environment already supports them
- No React, Vue, Inertia or Livewire unless explicitly approved

ADDON-READY DESIGN
Future addons must register providers, routes, migrations, views, permissions, menu items, workflow triggers/actions,
listeners and scheduled jobs without modifying core source files.
Use dedicated module registry tables; do not assume the existing plugins table is a safe runtime addon manager.

FIRST RELEASE INTEGRATIONS

Core:
- Manual trigger
- Scheduled trigger
- Generic incoming webhook
- Generic outgoing HTTP request
- REST API
- Existing global email notification system

First addons:
- Telegram Bot
- Slack Incoming Webhook
- WooCommerce
- Stripe
- WhatsApp Cloud API
- Google Calendar

DEVELOPMENT RULES
- Inspect before changing.
- Keep controllers thin; use services/actions, Form Requests, policies and transactions.
- Every tenant query must be isolated.
- Encrypt integration secrets.
- Add idempotency, retries and delivery logs.
- Never fake command or test results.
- Do not start the next phase automatically.
- After each phase report files, migrations, routes, tests, commands, manual verification and limitations.

Wait for my phase-specific prompt.

Phase 0 - Mandatory Source Code and Database Audit
PHASE 0: MANDATORY EXISTING PROJECT AUDIT. DO NOT WRITE FEATURE CODE.

Inspect the complete repository and compare it with the MinStack database.

Audit and report:

1. Laravel and PHP versions, composer packages and frontend packages.
2. Admin and user guards, middleware and authentication routes.
3. Models and relationships for Admin, User, Role, Permission, Transaction, Deposit, Gateway and NotificationTemplate.
4. How admin permissions and user permissions are checked in controllers/views.
5. Meaning and current usage of users.parent_id and roles.user_id.
6. Existing route prefixes, layouts, helpers, traits, repositories/services and coding conventions.
7. Existing queue, scheduler, cron, mail and notification implementation.
8. Existing menu generation and whether addons can register menu items safely.
9. Migration history versus SQL dump; identify tables that exist only in dump or migrations.
10. Risks of adding user-based tenancy and module architecture.

Deliver a compatibility matrix:

- Reuse unchanged
- Extend safely
- New table required
- Conflict/risk

Propose exact migration order, but do not create migrations yet.

Stop after the audit report.

Phase 1 - Tenancy Foundation Using users.parent_id

PHASE 1: IMPLEMENT USER-BASED TENANCY FOUNDATION.

Use the approved Phase 0 audit findings.

Requirements:
- Do not create tenants/businesses table.
- Preserve users.parent_id and current behavior.
- Define owner as parent_id=0 and staff as parent_id=owner id, unless audit proves an existing compatible convention that
must be preserved.
- Add reusable User::effectiveTenantId() or equivalent.
- Create TenantContext service and ResolveTenant middleware.
- Create tenant_profiles table with tenant_id unique and business profile fields.
- Add safe tenant query helpers/scopes without breaking Super Admin queries.
- Add owner profile CRUD using existing user layout and Bootstrap.
- Add cross-tenant authorization tests.
- Existing admin, registration, deposits, withdrawals and transactions must still work.

Before migration, show the migration and compatibility impact. Then implement, test and stop.

Phase 2 - Owner Staff and Existing User Permission Reuse

PHASE 2: STAFF MANAGEMENT USING EXISTING USERS, ROLES AND PERMISSIONS.
Do not install a duplicate permission package unless the existing implementation is unusable and I approve replacement.

Implement:
- Owner can create/edit/activate/suspend staff.
- Staff row uses parent_id=effective owner id.
- Reuse role_id, roles, permissions and permission_roles.
- Verify roles.user_id semantics; scope tenant roles safely if supported.
- Add automation permissions without changing existing permission slugs.
- Prevent staff from changing parent_id, balance, KYC, verification or financial fields.
- Super Admin can inspect all staff through existing admin panel.
- Bootstrap staff and role screens consistent with existing theme.
- Policy and tenant-isolation tests.

Stop after completion and audit.

Phase 3 - Addon Core and Module Registry

PHASE 3: ADDON-READY MODULE SYSTEM.

First inspect the existing plugins table and plugin code. Do not repurpose it if doing so can break current plugin settings.

Create dedicated tables if approved:

modules, module_versions, module_dependencies, user_modules, module_installation_logs.

Implement:
- ModuleRegistry, ManifestValidator, DependencyResolver and ModuleManager.
- [Link] contract.
- discover, install, enable, disable, update and uninstall lifecycle.
- Core version compatibility.
- Per-owner enablement using tenant_id/effective owner id.
- Registration hooks for providers, routes, migrations, permissions, menus and workflow nodes.
- Reject path traversal and core file replacement.
- DemoModule only for tests.
- Existing plugins feature must remain functional.

Stop after module lifecycle tests.

Phase 4 - Plan, Subscription and Existing Wallet Integration

PHASE 4: PLANS, SUBSCRIPTIONS AND USAGE LIMITS USING EXISTING FINANCE TABLES.

Reuse [Link], transactions, deposits, gateways and gateway_currencies.

Do not create a second wallet or deposit ledger.

Create only required business tables:

plans, plan_features, subscriptions, subscription_logs, usage_counters, usage_records.

Implement:
- Super Admin plan CRUD in existing admin panel and permission system.
- Owner plan purchase from existing balance/deposit flow.
- Every debit/credit must use the existing transaction service/convention and trx/remark pattern.
- Atomic balance updates with transactions and row locking where needed.
- Trial, expiry, grace period, upgrade and renewal.
- Limits: staff, workflows, runs, API calls, webhooks, integrations and addons.
- No withdrawal change.
- Tests for insufficient balance, duplicate charge and rollback.

Stop after finance compatibility verification.

Phase 5 - Contacts, Tags, Notes and Tasks

PHASE 5: CORE BUSINESS DATA.

Create tenant-owned tables:

contacts, tags, contact_tag, contact_notes, contact_activities, tasks.

Rules:
- tenant_id is always derived from TenantContext.
- Use existing users for assignment and creator fields.
- CRUD, search, filters, notes, tags, task assignment and status changes.
- Dispatch domain events: ContactCreated, ContactUpdated, ContactTagged, TaskCreated, TaskCompleted.
- Add permissions through existing permission system.
- Bootstrap UI consistent with current project.
- Audit logs and tenant isolation tests.

Do not build workflow execution yet. Stop after Phase 5.

Phase 6 - Workflow Data Model and Drawflow Builder

PHASE 6: VISUAL WORKFLOW BUILDER FOUNDATION.

Use Blade, Bootstrap 5 and Drawflow with normal JavaScript/jQuery. No SPA framework.

Create:
workflows, workflow_versions, workflow_nodes, workflow_edges, workflow_variables, workflow_templates.

Node palette:
Triggers: manual, contact_created, task_completed, webhook_received, scheduled.
Conditions: field condition operators.
Control: branch, delay, approval, stop.
Actions: create_task, add_tag, send_existing_email_notification, outgoing_http_request, write_log.

Implement draft/publish/versioning, drag-drop, edge connect, settings modal, AJAX save/load, server-side graph validation,
duplicate and preview.

Do not execute workflows yet. Stop after builder tests.

Phase 7 - Queue-Based Workflow Execution Engine

PHASE 7: WORKFLOW RUNTIME.
Create:
workflow_runs, workflow_run_nodes, workflow_run_logs, workflow_run_variables, workflow_failures,
workflow_wait_states, idempotency_keys.

Implement registry-based handlers, trigger matcher, context, condition evaluator, branch resolver, node executor, retry
service and queue jobs.

Required protections:
- tenant isolation
- idempotency
- max step limit
- loop detection
- transaction safety
- timeout and retry
- no long-running controller request

Initial executable nodes:

manual, contact_created, task_completed, field_condition, branch, delay, stop, create_task, add_tag, existing notification
email, write_log.

Add success, branch, delay, retry, failure and duplicate-event tests. Stop.

Phase 8 - REST API and Generic Webhook

PHASE 8: TENANT REST API AND GENERIC WEBHOOKS.

Create API keys with hashed secrets, scopes, expiry, revoke, rate limits and last-used data.
Create API request logs, incoming webhook endpoints/requests and outgoing HTTP delivery logs.

Endpoints:
POST contacts, PUT contacts/{id}, POST tasks, POST events, POST workflows/{id}/trigger.

Incoming webhook:
- endpoint key
- optional HMAC/signature
- header rules
- payload mapping
- event type
- raw log
- idempotency

Outgoing HTTP action:

- SSRF protection
- method, URL allow rules, headers, query, JSON mapping, timeout and retries
- redact secrets from logs

Connect webhook trigger/action to runtime. Add API docs and tests. Stop.
Phase 9 - Existing Notification Engine Adapter
PHASE 9: ADAPT EXISTING NOTIFICATION SYSTEM FOR AUTOMATION.

Audit notification_templates, notification_logs, general_settings.mail_config and current helper/service.

Do not create a duplicate global email engine.

Implement an adapter that workflow actions can call using existing templates and shortcode conventions.
- tenant-aware recipient and workflow variables
- queued delivery if compatible
- delivery status in workflow logs
- no secret exposure
- test email flow

Tenant custom SMTP must remain an optional future addon, not overwrite global settings.
Stop after regression tests of existing notifications.

Phase 10 - Approval and Advanced Delay

PHASE 10: HUMAN APPROVAL AND DELAY.

Create approval_requests, approval_actions and use workflow_wait_states.

Approvers: specific user, role, owner.
Statuses: pending, approved, rejected, expired, cancelled.
Implement inbox, details, comment, approve/reject, expiry, reminders and workflow resume paths.
Delay: minutes/hours/days/until date/business time with tenant timezone.
Use queue and scheduler; do not poll aggressively.
Add tests and stop.

Phase 11 - Telegram and Slack Addons

PHASE 11: TELEGRAM AND SLACK AS STANDALONE ADDONS.

Build each through the module architecture, not core-specific controllers.

Use encrypted credentials, connection test, workflow action registration and delivery logs.
Telegram: bot token + chat id.
Slack: incoming webhook URL.
Mock external HTTP calls in tests.
Disable/uninstall must remove workflow nodes safely without corrupting existing workflow versions.
Stop after addon lifecycle tests.

Phase 12 - WooCommerce Addon

PHASE 12: WOOCOMMERCE ADDON.

Triggers: order created/updated/completed/refunded and customer created.

Actions: add order note, update order status, update stock.
Implement credentials encryption, test connection, webhook signature, normalization, contact matching, idempotency,
retry and logs.
All WooCommerce logic must remain inside addon boundaries.
Mock API tests. Stop.
Phase 13 - Stripe Tenant Integration Addon
PHASE 13: STRIPE ADDON FOR TENANT BUSINESS AUTOMATION.

Keep this separate from platform plan/deposit billing.

Triggers: payment succeeded/failed, refund, subscription and invoice events.
Actions: create customer, payment link, refund and cancel subscription.
Use signature validation, encrypted keys, test/live modes, event idempotency and mocked tests.
Stop.

Phase 14 - WhatsApp Cloud API Addon

PHASE 14: OFFICIAL META WHATSAPP CLOUD API ADDON.

Credentials: app id/secret, token, phone number id, WABA id and verify token.
Triggers: incoming, delivered, read, failed.
Actions: text inside valid service window, approved template, media.
Enforce Meta messaging rules; do not use unofficial QR providers.
Webhook verification/signature, encrypted secrets, message logs, retry and mocked tests.
Stop.

Phase 15 - Google Calendar Addon

PHASE 15: GOOGLE CALENDAR ADDON.

OAuth 2.0, token refresh/encryption, calendar selection and disconnect.

Triggers: event created/updated/cancelled/starting.
Actions: create/update/delete event and add attendee.
Handle tenant timezone, mapping, retries and mocked tests.
Stop.

Phase 16 - Dashboards, Reports and Operational Logs

PHASE 16: DASHBOARDS AND REPORTS.

Tenant dashboard: workflows, runs, failures, approvals, delayed runs, API/webhook usage and plan limits.
Super Admin dashboard: owners, staff, subscriptions, deposits/revenue based on existing finance tables, workflow health,
modules, queues and failed jobs.
Use aggregate/rollup queries and indexes; never scan huge raw log tables on every request.
Bootstrap filters, pagination and safe exports.
Tests and stop.

Phase 17 - Security, Upgrade Safety and CodeCanyon Packaging

PHASE 17: FINAL HARDENING AND RELEASE.

Audit tenant isolation, admin guard, permissions, CSRF/XSS/SQL injection, mass assignment, SSRF, webhook signatures,
rate limits, secret encryption/redaction, module package safety, financial transaction atomicity and login throttling.
Verify old MinStack features: admin permissions, user login, balance, deposit, withdrawal, transactions, gateways,
notifications, support, CMS and plugins.

Prepare installer/update system that never re-imports or overwrites existing customer data.
Provide cron/queue docs, module docs, API docs, demo workflows, rollback guide, backup checklist and CodeCanyon
packaging checklist.
Run all available tests honestly and stop.
6. Reusable Review and Fix Prompts
After Every Phase - Strict Audit Prompt
Audit only the phase just completed. Do not add next-phase features.

Check:
- compatibility with existing MinStack features
- tenant isolation using users.parent_id
- existing admin/user permissions
- validation and authorization
- migrations, indexes and foreign keys
- financial safety if balance/transactions are touched
- queue idempotency and retries
- secret handling
- code duplication and conventions
- Bootstrap UI consistency
- tests and manual flows

List Critical, High, Medium and Low issues. Fix Critical and High. Fix safe Medium/Low issues. Run relevant tests honestly
and report files changed, commands, results and manual verification. Stop.

Error Fix Prompt

Fix only this error. Do not add a new feature:

[PASTE FULL ERROR, STACK TRACE, URL, REQUEST AND RELEVANT LOG]

Find the root cause by inspecting related routes, middleware, controller, service, model, migration and database data.
Apply the smallest safe fix. Do not bypass permission, tenancy, validation or financial rules. Add a regression test and
report root cause, files changed, fix, tests and manual verification. Stop.

Existing Feature Regression Prompt

Run a regression audit to confirm the new automation work did not break the original MinStack kit.

Verify:
- Admin login and role permissions
- User registration/login/verification/KYC
- Parent/role behavior
- Balance display
- Deposits and gateway callbacks
- Transactions ledger
- Withdrawals
- Notification templates/logs
- Support tickets
- Frontend pages, menus, plugins and language

Do not redesign anything. Fix only regressions caused by our changes. Report evidence and stop.
Git Commit Preparation Prompt
Prepare this phase for a clean Git commit. Remove debug code and temporary files, check secrets, migration order,
formatting and tests. Show diff summary and suggest one Conventional Commit message. Do not commit automatically.

7. Recommended Build Order

1. Audit

2. Tenancy

3. Staff permissions

4. Addon core

5. Plans/wallet integration

6. Contacts/tasks

7. Workflow builder

8. Execution engine

9. API/webhooks

10. Notification adapter

11. Approval/delay

12. Telegram/Slack

13. WooCommerce

14. Stripe

15. WhatsApp

16. Calendar

17. Reports

18. Security/release

8. Important Warnings
 `users.parent_id` বর্ত মানে অন্য business logic-এ ব্যবহৃত হলে Phase 0 audit ছাড়া tenancy assumption
প্রয়োগ করবেন না।
 `roles.user_id` owner-scoped role বোঝাতে পারে; code relation verify না করে schema change করবেন না।
 Existing `plugins` table third-party scripts/settings-এর জন্য; module manager বানানোর আগে source
code inspect জরুরি।
 Existing financial tables-এ foreign key type mismatch আছে (`[Link]` bigint unsigned, কিছু `user_id` int
unsigned)। নতুন migration-এ type compatibility সতর্ক ভাবে handle করতে হবে।
 SQL dump-এ indexes/constraints পরবর্তী ALTER statements-এ থাকতে পারে; agent migration files audit
করবে।
 Only database was reviewed. Final implementation decisions must follow the actual source code when
it differs from assumptions.

End of guide