203 lines
3.2 KiB
Markdown
203 lines
3.2 KiB
Markdown
# Cline Development Super Prompt
|
|
|
|
You are acting as a senior software engineer working on this repository.
|
|
|
|
Before making any modifications you must understand the project structure and current implementation.
|
|
|
|
Always read:
|
|
|
|
`docs/ai-project-context.md`
|
|
|
|
before implementing tasks.
|
|
|
|
---
|
|
|
|
## Working Method
|
|
|
|
When given a task follow this process.
|
|
|
|
Step 1
|
|
Search the repository for relevant code.
|
|
|
|
Step 2
|
|
Identify the correct extension point for the feature.
|
|
|
|
Step 3
|
|
Design the minimal safe implementation.
|
|
|
|
Step 4
|
|
Modify only the required files.
|
|
|
|
Step 5
|
|
Verify existing functionality remains intact.
|
|
|
|
Never rewrite large parts of the system unless explicitly instructed.
|
|
|
|
---
|
|
|
|
## Repository Exploration Rules
|
|
|
|
Before editing files:
|
|
|
|
Search for related implementations.
|
|
|
|
Look for:
|
|
|
|
- plesk integration
|
|
- sync logic
|
|
- API routes
|
|
- database queries
|
|
- dashboard components
|
|
|
|
Use existing patterns instead of creating new ones.
|
|
|
|
---
|
|
|
|
## Database Rules
|
|
|
|
The project uses Supabase Postgres.
|
|
|
|
Never introduce breaking schema changes.
|
|
|
|
All schema updates must be done using safe migrations.
|
|
|
|
Never remove columns that may contain production data.
|
|
|
|
Always assume the database already contains data.
|
|
|
|
---
|
|
|
|
## Multi-Tenant Security
|
|
|
|
This system is multi-tenant.
|
|
|
|
Users belong to agencies.
|
|
|
|
All queries must respect agency boundaries.
|
|
|
|
Never bypass Supabase Row Level Security.
|
|
|
|
Never expose data across agencies.
|
|
|
|
---
|
|
|
|
## Plesk Integration Safety
|
|
|
|
The platform interacts with Plesk servers using both REST API and CLI commands.
|
|
|
|
CLI output can vary between Plesk versions.
|
|
|
|
Always parse CLI output defensively.
|
|
|
|
Never assume fixed output formatting.
|
|
|
|
External integration failures must not crash the application.
|
|
|
|
---
|
|
|
|
## Sync Pipeline Rules
|
|
|
|
The sync system is critical to the platform.
|
|
|
|
Never break existing sync behaviour.
|
|
|
|
If one subscription fails during sync:
|
|
|
|
Continue processing the rest.
|
|
|
|
Log the failure.
|
|
|
|
Do not abort the entire sync job.
|
|
|
|
---
|
|
|
|
## Logging Requirements
|
|
|
|
Operational events should be written to:
|
|
|
|
`actions_log`
|
|
|
|
Examples include:
|
|
|
|
- instance_connected
|
|
- sync_started
|
|
- sync_completed
|
|
- subscription_suspended
|
|
- subscription_unsuspended
|
|
|
|
Logging errors must never break primary workflows.
|
|
|
|
---
|
|
|
|
## UI Safety
|
|
|
|
Frontend components must:
|
|
|
|
Handle missing or null data safely.
|
|
|
|
Avoid crashing when API responses change.
|
|
|
|
Display statuses using badges instead of raw text.
|
|
|
|
---
|
|
|
|
## Git Workflow
|
|
|
|
The repository uses:
|
|
|
|
`master` as the default branch.
|
|
|
|
All development must occur in feature branches.
|
|
|
|
Example workflow:
|
|
|
|
```bash
|
|
git checkout master
|
|
git pull
|
|
git checkout -b feature/<feature-name>
|
|
```
|
|
|
|
Commit frequently with clear commit messages.
|
|
|
|
Never commit directly to master.
|
|
|
|
---
|
|
|
|
## Implementation Guidelines
|
|
|
|
Prefer small modular changes.
|
|
|
|
Avoid large refactors unless requested.
|
|
|
|
Keep API routes lightweight.
|
|
|
|
Place integration logic inside lib folders.
|
|
|
|
Reuse existing utilities where possible.
|
|
|
|
---
|
|
|
|
## Error Handling
|
|
|
|
External services can fail.
|
|
|
|
Always implement safe error handling.
|
|
|
|
Prefer returning partial results over failing the entire operation.
|
|
|
|
Log unexpected behaviour.
|
|
|
|
---
|
|
|
|
## Expected Output
|
|
|
|
When implementing tasks you should:
|
|
|
|
Modify only the required files.
|
|
|
|
Maintain existing architecture.
|
|
|
|
Add clear commit messages.
|
|
|
|
Ensure the application remains stable.
|