initial: bootstrap from BukidBountyApp base
This commit is contained in:
31
.agents/rules/artisan-commands.md
Normal file
31
.agents/rules/artisan-commands.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
# Rule: Running PHP Artisan Commands
|
||||
|
||||
## ❗ Important
|
||||
|
||||
Never execute `php artisan` commands directly on the host machine.
|
||||
|
||||
## ✅ Correct Approach
|
||||
|
||||
All Artisan commands **must be executed inside the Docker container**.
|
||||
|
||||
## 📦 Reason
|
||||
|
||||
The application environment (PHP version, extensions, dependencies) is fully configured inside the container. Running commands outside may cause:
|
||||
|
||||
- Version mismatches
|
||||
- Missing dependencies
|
||||
- Inconsistent behavior
|
||||
|
||||
## 🛠️ How to Execute
|
||||
|
||||
Use one of the following patterns depending on the setup:
|
||||
|
||||
### Docker Compose
|
||||
|
||||
```bash
|
||||
docker compose exec <app_service> php artisan <command>
|
||||
```
|
||||
17
.agents/rules/build-restart.md
Normal file
17
.agents/rules/build-restart.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
## Build & Deployment Rule
|
||||
|
||||
- After completing any task, you must:
|
||||
1. Run the build process:
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
2. Restart the Docker container to apply changes:
|
||||
```bash
|
||||
docker restart bukidbountyapp
|
||||
```
|
||||
|
||||
- Ensure both steps are executed successfully before considering the task complete.
|
||||
69
.agents/rules/caveman.md
Normal file
69
.agents/rules/caveman.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
trigger: manual
|
||||
---
|
||||
|
||||
caveman
|
||||
---
|
||||
name: caveman
|
||||
description: >
|
||||
Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman
|
||||
while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra,
|
||||
wenyan-lite, wenyan-full, wenyan-ultra.
|
||||
Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
|
||||
"be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
|
||||
Use caveman talk in thinking as well for less tokens
|
||||
---
|
||||
|
||||
Respond terse like smart caveman. All technical substance stay. Only fluff die.
|
||||
|
||||
Default: **full**. Switch: `/caveman lite|full|ultra`.
|
||||
|
||||
## Rules
|
||||
|
||||
Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.
|
||||
|
||||
Pattern: `[thing] [action] [reason]. [next step].`
|
||||
|
||||
Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
|
||||
Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
|
||||
|
||||
## Intensity
|
||||
|
||||
| Level | What change |
|
||||
|-------|------------|
|
||||
| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
|
||||
| **full** | Drop articles, fragments OK, short synonyms. Classic caveman |
|
||||
| **ultra** | Abbreviate (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough |
|
||||
| **wenyan-lite** | Semi-classical. Drop filler/hedging but keep grammar structure, classical register |
|
||||
| **wenyan-full** | Maximum classical terseness. Fully 文言文. 80-90% character reduction. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其) |
|
||||
| **wenyan-ultra** | Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse |
|
||||
|
||||
Example — "Why React component re-render?"
|
||||
- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
|
||||
- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
|
||||
- ultra: "Inline obj prop → new ref → re-render. `useMemo`."
|
||||
- wenyan-lite: "組件頻重繪,以每繪新生對象參照故。以 useMemo 包之。"
|
||||
- wenyan-full: "物出新參照,致重繪。useMemo .Wrap之。"
|
||||
- wenyan-ultra: "新參照→重繪。useMemo Wrap。"
|
||||
|
||||
Example — "Explain database connection pooling."
|
||||
- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
|
||||
- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
|
||||
- ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
|
||||
- wenyan-full: "池reuse open connection。不每req新開。skip handshake overhead。"
|
||||
- wenyan-ultra: "池reuse conn。skip handshake → fast。"
|
||||
|
||||
## Auto-Clarity
|
||||
|
||||
Drop caveman for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user confused. Resume caveman after clear part done.
|
||||
|
||||
Example — destructive op:
|
||||
> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
|
||||
> ```sql
|
||||
> DROP TABLE users;
|
||||
> ```
|
||||
> Caveman resume. Verify backup exist first.
|
||||
|
||||
## Boundaries
|
||||
|
||||
Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.
|
||||
18
.agents/rules/db-show-alternative.md
Normal file
18
.agents/rules/db-show-alternative.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
# 📦 Database Table Inspection (Hypervel / Older Laravel)
|
||||
|
||||
## ❗ Important
|
||||
The `php artisan db:show` command is **NOT available** because this project uses an older version of Laravel (via Hypervel).
|
||||
|
||||
**Do NOT use:**
|
||||
```bash
|
||||
php artisan db:show --table=<table_name>
|
||||
|
||||
|
||||
**Use the Following**
|
||||
docker compose exec bukidbountyapp php artisan tinker
|
||||
|
||||
DB::select('DESCRIBE table_name');
|
||||
23
.agents/rules/farmer-management.md
Normal file
23
.agents/rules/farmer-management.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
# Agent Rule: Building the Farmer Management Module
|
||||
|
||||
When implementing the Farmer Management Module, adhere to the following planning specifications:
|
||||
|
||||
## 🏗️ Data Architecture
|
||||
- **Primary Model**: `FarmerProfile` (Target File: `app/Models/Market/FarmerProfile.php`)
|
||||
- **Key Fields**: `hashkey`, `user_id`, `organization_id`, `farm_name`, `farm_location`, `verification_status`.
|
||||
- **Verification Statuses**: `UNVERIFIED`, `PENDING`, `VERIFIED`, `REJECTED`.
|
||||
- **Reference**: Detailed plan at `ai-docs/modules/farmer_management_module.md`.
|
||||
|
||||
## 🛠️ Implementation Requirements
|
||||
1. **Core Logic**: Extend the current user/member system. Implement logic in `app/Http/Controllers/Market/FarmerController.php`.
|
||||
2. **Standard Fields**: Every record must have `created_by`, `updated_by`, `is_active`, and `hashkey`.
|
||||
3. **Frontend**: Build management interfaces in `resources/js/Pages/Market/`.
|
||||
- `FarmerProfileEdit.vue` for detailed registration.
|
||||
- `VerificationDashboard.vue` for admin reviews.
|
||||
|
||||
## 📄 Documentation Integration
|
||||
Ensure that any new enums or key fields are added to `ai-docs/dictionary.md` to maintain system-wide consistency.
|
||||
79
.agents/rules/gemini-subagents.md
Normal file
79
.agents/rules/gemini-subagents.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
# Using Gemini CLI for Large Codebase Analysis
|
||||
|
||||
When analyzing large codebases or multiple files, use the Gemini CLI with its massive
|
||||
context window. Use `gemini -p` to leverage Google Gemini's large context capacity.
|
||||
You can also run tasks with Gemini to prevent overthinking. Run tasks like curl and getting and explaining its output or other linux commands.
|
||||
|
||||
## File and Directory Inclusion Syntax
|
||||
|
||||
Use the `@` syntax to include files and directories in your Gemini prompts. The paths should be relative to WHERE you run the
|
||||
gemini command:
|
||||
|
||||
### Examples:
|
||||
|
||||
**Single file analysis:**
|
||||
gemini -p "@src/main.py Explain this file's purpose and structure"
|
||||
|
||||
Multiple files:
|
||||
gemini -p "@package.json @src/index.js Analyze the dependencies used in the code"
|
||||
|
||||
Entire directory:
|
||||
gemini -p "@src/ Summarize the architecture of this codebase"
|
||||
|
||||
Multiple directories:
|
||||
gemini -p "@src/ @tests/ Analyze test coverage for the source code"
|
||||
|
||||
Current directory and subdirectories:
|
||||
gemini -p "@./ Give me an overview of this entire project"
|
||||
|
||||
# Or use --all_files flag:
|
||||
gemini --all_files -p "Analyze the project structure and dependencies"
|
||||
|
||||
Implementation Verification Examples
|
||||
|
||||
Check if a feature is implemented:
|
||||
gemini -p "@src/ @lib/ Has dark mode been implemented in this codebase? Show me the relevant files and functions"
|
||||
|
||||
Verify authentication implementation:
|
||||
gemini -p "@src/ @middleware/ Is JWT authentication implemented? List all auth-related endpoints and middleware"
|
||||
|
||||
Check for specific patterns:
|
||||
gemini -p "@src/ Are there any React hooks that handle WebSocket connections? List them with file paths"
|
||||
|
||||
Verify error handling:
|
||||
gemini -p "@src/ @api/ Is proper error handling implemented for all API endpoints? Show examples of try-catch blocks"
|
||||
|
||||
Check for rate limiting:
|
||||
gemini -p "@backend/ @middleware/ Is rate limiting implemented for the API? Show the implementation details"
|
||||
|
||||
Verify caching strategy:
|
||||
gemini -p "@src/ @lib/ @services/ Is Redis caching implemented? List all cache-related functions and their usage"
|
||||
|
||||
Check for specific security measures:
|
||||
gemini -p "@src/ @api/ Are SQL injection protections implemented? Show how user inputs are sanitized"
|
||||
|
||||
Verify test coverage for features:
|
||||
gemini -p "@src/payment/ @tests/ Is the payment processing module fully tested? List all test cases"
|
||||
|
||||
When to Use Gemini CLI
|
||||
|
||||
Use gemini -p when:
|
||||
- Analyzing entire codebases or large directories
|
||||
- Comparing multiple large files
|
||||
- Need to understand project-wide patterns or architecture
|
||||
- Current context window is insufficient for the task
|
||||
- Working with files totaling more than 100KB
|
||||
- Verifying if specific features, patterns, or security measures are implemented
|
||||
- Checking for the presence of certain coding patterns across the entire codebase
|
||||
|
||||
Important Notes
|
||||
|
||||
- Paths in @ syntax are relative to your current working directory when invoking gemini
|
||||
- The CLI will include file contents directly in the context
|
||||
- No need for --yolo flag for read-only analysis
|
||||
- Gemini's context window can handle entire codebases that would overflow Your context
|
||||
- When checking implementations, be specific about what you're looking for to get accurate results
|
||||
23
.agents/rules/shipment-module.md
Normal file
23
.agents/rules/shipment-module.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
# Agent Rule: Building the Shipment Module
|
||||
|
||||
When implementing the Shipment Module, adhere to the following planning specifications:
|
||||
|
||||
## 🏗️ Data Architecture
|
||||
- **Primary Model**: `Shipment` (Target File: `app/Models/Market/Shipment.php`)
|
||||
- **Key Fields**: `hashkey`, `transaction_id`, `store_id`, `customer_id`, `courier_id`, `tracking_number`, `status`.
|
||||
- **Status Enums**: `PENDING`, `PICKED_UP`, `IN_TRANSIT`, `DELIVERED`, `FAILED`, `RETURNED`.
|
||||
- **Reference**: Detailed plan at `ai-docs/modules/shipment_module.md`.
|
||||
|
||||
## 🛠️ Implementation Requirements
|
||||
1. **Core Logic**: Implement in `app/Http/Controllers/Market/ShipmentController.php`.
|
||||
2. **Standard Fields**: Ensure every new table includes `created_by`, `updated_by`, `is_active`, and `hashkey` (300, unique) as per the Project Dictionary.
|
||||
3. **Frontend**: Use Vue 3 Composition API in `resources/js/Pages/Market/`.
|
||||
- `ShipmentList.vue` for tracking.
|
||||
- `ShipmentDetail.vue` for timeline and management.
|
||||
|
||||
## 📦 Database Standards
|
||||
Use migrations to create the `shipments` and `couriers` tables, ensuring foreign key constraints to `global_transactions`, `stores`, and `cst`.
|
||||
9
.agents/rules/use-claude.md
Normal file
9
.agents/rules/use-claude.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
you can use claude to verify code you created. and to explain code files just make sure to be specific
|
||||
|
||||
command
|
||||
|
||||
claude -p "prompt"
|
||||
9
.agents/rules/words-dictionary.md
Normal file
9
.agents/rules/words-dictionary.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
trigger: always_on
|
||||
---
|
||||
|
||||
Create a dictionary file named dictionary.md on ai-docs if not exists
|
||||
|
||||
read the dictionary file named dictionary.md and check if there are things there that can help you understand more of what the user is requesting. this could contain definition and target files
|
||||
|
||||
update the dictionary file once you found things that might make the you understand things a little bit better on the next request. after updating make sure that to commit and push that single dictionary.md file with the commit message being the summary of changes
|
||||
Reference in New Issue
Block a user