@ainative/cody-cli 0.2.7 → 0.2.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.ainative/AINATIVE.md +164 -0
- package/.ainative/CRITICAL_FILE_PLACEMENT_RULES.md +139 -0
- package/.ainative/README.md +163 -0
- package/.ainative/SDK_PUBLISHING_GUIDELINES.md +262 -0
- package/.ainative/git-rules.md +150 -0
- package/.ainative/settings.json +116 -0
- package/.ainative/skills/ci-cd-compliance/SKILL.md +33 -0
- package/.ainative/skills/code-quality/SKILL.md +35 -0
- package/.ainative/skills/file-placement/SKILL.md +59 -0
- package/.ainative/skills/git-workflow/SKILL.md +116 -0
- package/.ainative/skills/local-environment-check/SKILL.md +78 -0
- package/.ainative/skills/mandatory-tdd/SKILL.md +112 -0
- package/.ainative/skills/mcp-builder/SKILL.md +150 -0
- package/.claude/RAILWAY_DEPLOYMENT_GUIDE.md +118 -0
- package/.claude/hooks/README.md +68 -0
- package/.claude/hooks/commit-msg +26 -0
- package/.claude/hooks/install-hooks.sh +46 -0
- package/.claude/hooks/pre-commit +62 -0
- package/.claude/mcp.json.example +31 -0
- package/.claude/settings.json +24 -0
- package/.claude/skills/ci-cd-compliance/SKILL.md +33 -0
- package/.claude/skills/code-quality/SKILL.md +35 -0
- package/.claude/skills/file-placement/SKILL.md +59 -0
- package/.claude/skills/git-workflow/SKILL.md +116 -0
- package/.claude/skills/local-environment-check/SKILL.md +78 -0
- package/.claude/skills/mandatory-tdd/SKILL.md +112 -0
- package/.claude/skills/mcp-builder/SKILL.md +150 -0
- package/.cody/CODY.md +17 -0
- package/.cody/hooks/commit-msg +7 -0
- package/.cody/hooks/pre-commit +8 -0
- package/.cody/mcp.json +9 -0
- package/.cody/mcp.json.example +9 -0
- package/.cody/skills/ci-cd-compliance/SKILL.md +12 -0
- package/.cody/skills/code-quality/SKILL.md +10 -0
- package/.cody/skills/database-best-practices/SKILL.md +13 -0
- package/.cody/skills/delivery-checklist/SKILL.md +13 -0
- package/.cody/skills/file-placement/SKILL.md +11 -0
- package/.cody/skills/git-workflow/SKILL.md +9 -0
- package/.cody/skills/mandatory-tdd/SKILL.md +10 -0
- package/package.json +4 -1
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: mcp-builder
|
|
3
|
+
description: Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node.js (MCP SDK).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# MCP Builder Guide
|
|
7
|
+
|
|
8
|
+
## What is an MCP Server?
|
|
9
|
+
|
|
10
|
+
Model Context Protocol (MCP) servers expose tools that AI agents (Claude Code, Cursor, Windsurf, etc.) can call directly. You can build custom MCP servers to integrate any API or service.
|
|
11
|
+
|
|
12
|
+
## Python -- FastMCP
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
pip install fastmcp
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
```python
|
|
19
|
+
# my_mcp_server.py
|
|
20
|
+
from fastmcp import FastMCP
|
|
21
|
+
import requests
|
|
22
|
+
|
|
23
|
+
mcp = FastMCP("my-tools")
|
|
24
|
+
API_KEY = "your_api_key"
|
|
25
|
+
BASE = "https://your-api.example.com"
|
|
26
|
+
|
|
27
|
+
@mcp.tool()
|
|
28
|
+
def get_status() -> dict:
|
|
29
|
+
"""Get current service status."""
|
|
30
|
+
return requests.get(
|
|
31
|
+
f"{BASE}/api/v1/status",
|
|
32
|
+
headers={"X-API-Key": API_KEY}
|
|
33
|
+
).json()
|
|
34
|
+
|
|
35
|
+
@mcp.tool()
|
|
36
|
+
def search_items(query: str, limit: int = 5) -> dict:
|
|
37
|
+
"""Search items by query."""
|
|
38
|
+
return requests.post(
|
|
39
|
+
f"{BASE}/api/v1/search",
|
|
40
|
+
headers={"X-API-Key": API_KEY},
|
|
41
|
+
json={"query": query, "limit": limit}
|
|
42
|
+
).json()
|
|
43
|
+
|
|
44
|
+
if __name__ == "__main__":
|
|
45
|
+
mcp.run()
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
python my_mcp_server.py
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Node.js -- MCP SDK
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
npm install @modelcontextprotocol/sdk
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
```typescript
|
|
59
|
+
// server.ts
|
|
60
|
+
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
|
|
61
|
+
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
|
|
62
|
+
|
|
63
|
+
const server = new Server(
|
|
64
|
+
{ name: 'my-mcp-server', version: '1.0.0' },
|
|
65
|
+
{ capabilities: { tools: {} } }
|
|
66
|
+
);
|
|
67
|
+
|
|
68
|
+
server.setRequestHandler('tools/list', async () => ({
|
|
69
|
+
tools: [{
|
|
70
|
+
name: 'get_status',
|
|
71
|
+
description: 'Get current service status',
|
|
72
|
+
inputSchema: { type: 'object', properties: {} }
|
|
73
|
+
}]
|
|
74
|
+
}));
|
|
75
|
+
|
|
76
|
+
server.setRequestHandler('tools/call', async (request) => {
|
|
77
|
+
if (request.params.name === 'get_status') {
|
|
78
|
+
const resp = await fetch('https://your-api.example.com/api/v1/status', {
|
|
79
|
+
headers: { 'X-API-Key': process.env.API_KEY! }
|
|
80
|
+
});
|
|
81
|
+
return { content: [{ type: 'text', text: JSON.stringify(await resp.json()) }] };
|
|
82
|
+
}
|
|
83
|
+
});
|
|
84
|
+
|
|
85
|
+
const transport = new StdioServerTransport();
|
|
86
|
+
await server.connect(transport);
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Configure in Claude Code
|
|
90
|
+
|
|
91
|
+
```json
|
|
92
|
+
// .claude/mcp.json
|
|
93
|
+
{
|
|
94
|
+
"mcpServers": {
|
|
95
|
+
"my-tools": {
|
|
96
|
+
"command": "python",
|
|
97
|
+
"args": ["my_mcp_server.py"],
|
|
98
|
+
"env": { "API_KEY": "your_api_key" }
|
|
99
|
+
}
|
|
100
|
+
}
|
|
101
|
+
}
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
For a published npm package:
|
|
105
|
+
```json
|
|
106
|
+
{
|
|
107
|
+
"mcpServers": {
|
|
108
|
+
"my-tools": {
|
|
109
|
+
"command": "npx",
|
|
110
|
+
"args": ["my-mcp-package"],
|
|
111
|
+
"env": { "API_KEY": "your_api_key" }
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
}
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
## SKILL.md Format
|
|
118
|
+
|
|
119
|
+
Every MCP tool should have a matching skill file so agents know when to call it:
|
|
120
|
+
|
|
121
|
+
```markdown
|
|
122
|
+
---
|
|
123
|
+
name: my-tool-name
|
|
124
|
+
description: One-line description. Use when (1) scenario, (2) scenario, (3) scenario.
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
# Tool Name
|
|
128
|
+
|
|
129
|
+
Brief description and usage examples.
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
Place in `.claude/skills/my-tool-name/SKILL.md`.
|
|
133
|
+
|
|
134
|
+
## Publish to npm
|
|
135
|
+
|
|
136
|
+
```bash
|
|
137
|
+
# package.json
|
|
138
|
+
{
|
|
139
|
+
"name": "my-mcp-server",
|
|
140
|
+
"version": "1.0.0",
|
|
141
|
+
"bin": { "my-mcp-server": "./dist/server.js" },
|
|
142
|
+
"main": "./dist/server.js"
|
|
143
|
+
}
|
|
144
|
+
|
|
145
|
+
npm publish
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
## References
|
|
149
|
+
|
|
150
|
+
- MCP spec: `https://modelcontextprotocol.io`
|
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
# Railway Deployment Guide
|
|
2
|
+
|
|
3
|
+
## Service Architecture
|
|
4
|
+
|
|
5
|
+
Production environments can use a multi-service architecture on Railway:
|
|
6
|
+
|
|
7
|
+
### Key Services
|
|
8
|
+
|
|
9
|
+
1. **API Gateway** (e.g., Kong) - Routes requests to backend services
|
|
10
|
+
2. **Backend** - Main application service (handles auth, users, billing, etc.)
|
|
11
|
+
3. **CMS** - Content management (e.g., Strapi)
|
|
12
|
+
4. **Database** - PostgreSQL database
|
|
13
|
+
|
|
14
|
+
### Critical: Deploy to the Correct Service
|
|
15
|
+
|
|
16
|
+
**ALWAYS deploy backend code to the correct backend service, NOT the gateway!**
|
|
17
|
+
|
|
18
|
+
## Deployment Commands
|
|
19
|
+
|
|
20
|
+
### 1. List All Services
|
|
21
|
+
```bash
|
|
22
|
+
railway status --json | jq -r '.services.edges[].node.name'
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
### 2. Deploy to Backend Service
|
|
26
|
+
```bash
|
|
27
|
+
# Option 1: Deploy with service flag (RECOMMENDED)
|
|
28
|
+
railway up --detach --service "your-backend-service"
|
|
29
|
+
|
|
30
|
+
# Option 2: Link to service first, then deploy
|
|
31
|
+
railway link --service "your-backend-service"
|
|
32
|
+
railway up --detach
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### 3. Check Deployment Status
|
|
36
|
+
```bash
|
|
37
|
+
railway status --json | jq -r '.services.edges[] | select(.node.name == "your-service") | .node.serviceInstances.edges[0].node.latestDeployment'
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Common Mistakes to Avoid
|
|
41
|
+
|
|
42
|
+
- **DON'T:** Deploy without specifying service (deploys to wrong service)
|
|
43
|
+
- **DO:** Always specify the service explicitly
|
|
44
|
+
- **DON'T:** Assume `railway up` knows which service based on the code
|
|
45
|
+
- **DO:** Use Railway docs to understand service structure first
|
|
46
|
+
|
|
47
|
+
## GitHub CI/CD Integration
|
|
48
|
+
|
|
49
|
+
Railway can auto-deploy from GitHub when CI passes. If CI fails:
|
|
50
|
+
|
|
51
|
+
### Option 1: Fix CI and Let Auto-Deploy Work
|
|
52
|
+
```bash
|
|
53
|
+
# Fix failing tests, commit fixes, push to main
|
|
54
|
+
# Railway auto-deploys when CI passes
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### Option 2: Force Deploy (Bypass CI)
|
|
58
|
+
```bash
|
|
59
|
+
# Use when change is critical and safe despite CI failures
|
|
60
|
+
railway up --detach --service your-backend-service
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Verifying Deployment
|
|
64
|
+
|
|
65
|
+
### 1. Check Health Endpoint
|
|
66
|
+
```bash
|
|
67
|
+
curl https://your-domain.com/health | jq
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
### 2. Check Railway Dashboard
|
|
71
|
+
- Build logs: https://railway.com/project/{project-id}/service/{service-id}
|
|
72
|
+
- Deployment status
|
|
73
|
+
- Error logs if deployment failed
|
|
74
|
+
|
|
75
|
+
## Database Connection Issues
|
|
76
|
+
|
|
77
|
+
If you see "Database connection failed" after deployment:
|
|
78
|
+
|
|
79
|
+
1. **Wait 2-3 minutes** - Service might still be starting
|
|
80
|
+
2. **Check Railway logs** - Look for connection errors
|
|
81
|
+
3. **Verify environment variables** - DATABASE_URL must be set correctly
|
|
82
|
+
4. **Check database service status** - Ensure PostgreSQL is running
|
|
83
|
+
|
|
84
|
+
## Troubleshooting
|
|
85
|
+
|
|
86
|
+
### Issue: "Service not found"
|
|
87
|
+
**Solution:** List services first, use exact service name
|
|
88
|
+
```bash
|
|
89
|
+
railway status --json | jq -r '.services.edges[].node.name'
|
|
90
|
+
railway up --service your-service # Use exact name from list
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Issue: "Multiple services found"
|
|
94
|
+
**Solution:** Always use `--service` flag explicitly
|
|
95
|
+
|
|
96
|
+
### Issue: Deployment succeeds but changes don't appear
|
|
97
|
+
**Possible causes:**
|
|
98
|
+
1. Deployed to wrong service (check service name)
|
|
99
|
+
2. Code not committed to git (Railway deploys from git, not local files)
|
|
100
|
+
3. Deployment still in progress (wait longer)
|
|
101
|
+
4. Cache issue (try hard refresh or new incognito window)
|
|
102
|
+
|
|
103
|
+
## Best Practices
|
|
104
|
+
|
|
105
|
+
1. **Always verify service name before deploying**
|
|
106
|
+
2. **Use explicit service flags**
|
|
107
|
+
3. **Check deployment status after deploying**
|
|
108
|
+
4. **Use Railway dashboard for detailed logs**
|
|
109
|
+
|
|
110
|
+
## Quick Reference
|
|
111
|
+
|
|
112
|
+
```bash
|
|
113
|
+
# Deploy backend code
|
|
114
|
+
railway up --detach --service "your-backend-service"
|
|
115
|
+
|
|
116
|
+
# Check all services and their status
|
|
117
|
+
railway status --json | jq -r '.services.edges[].node | {name, latestDeployment: .serviceInstances.edges[0].node.latestDeployment.status}'
|
|
118
|
+
```
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# Git Hooks - File Placement & Commit Message Enforcement
|
|
2
|
+
|
|
3
|
+
## Quick Install
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
# From your project root:
|
|
7
|
+
bash .claude/hooks/install-hooks.sh
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
Or if using .ainative:
|
|
11
|
+
```bash
|
|
12
|
+
bash .ainative/hooks/install-hooks.sh
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## What Gets Installed
|
|
16
|
+
|
|
17
|
+
### 1. Pre-commit Hook
|
|
18
|
+
**Blocks:**
|
|
19
|
+
- .md files in root directory (except README.md, CLAUDE.md)
|
|
20
|
+
- .sh scripts in root directory
|
|
21
|
+
- .sh scripts in backend/ (except backend/start.sh)
|
|
22
|
+
- .md files in src/backend/
|
|
23
|
+
|
|
24
|
+
### 2. Commit-msg Hook
|
|
25
|
+
**Blocks:**
|
|
26
|
+
- "Claude", "Anthropic", "claude.com"
|
|
27
|
+
- "ChatGPT", "OpenAI" (as code author)
|
|
28
|
+
- "Copilot", "GitHub Copilot"
|
|
29
|
+
- "Generated with", "Powered by" + third-party tools
|
|
30
|
+
- "Co-Authored-By: Claude/ChatGPT/Copilot"
|
|
31
|
+
|
|
32
|
+
## Testing
|
|
33
|
+
|
|
34
|
+
After installation, test with:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
# Test file placement (should block)
|
|
38
|
+
touch test.md
|
|
39
|
+
git add test.md
|
|
40
|
+
git commit -m "test"
|
|
41
|
+
|
|
42
|
+
# Expected: BLOCKED
|
|
43
|
+
|
|
44
|
+
# Test commit message (should block)
|
|
45
|
+
git commit -m "test
|
|
46
|
+
|
|
47
|
+
Generated with Claude"
|
|
48
|
+
|
|
49
|
+
# Expected: BLOCKED
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Manual Installation
|
|
53
|
+
|
|
54
|
+
If the script doesn't work, install manually:
|
|
55
|
+
|
|
56
|
+
```bash
|
|
57
|
+
cp .claude/hooks/pre-commit .git/hooks/pre-commit
|
|
58
|
+
cp .claude/hooks/commit-msg .git/hooks/commit-msg
|
|
59
|
+
chmod +x .git/hooks/pre-commit
|
|
60
|
+
chmod +x .git/hooks/commit-msg
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Related Documentation
|
|
64
|
+
|
|
65
|
+
- `.ainative/CRITICAL_FILE_PLACEMENT_RULES.md`
|
|
66
|
+
- `.ainative/git-rules.md`
|
|
67
|
+
- `.claude/skills/file-placement/SKILL.md`
|
|
68
|
+
- `.claude/skills/git-workflow/`
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
# Commit Message Hook - AI Attribution Enforcement
|
|
3
|
+
# Blocks third-party AI tool attribution in commit messages
|
|
4
|
+
|
|
5
|
+
COMMIT_MSG_FILE=$1
|
|
6
|
+
|
|
7
|
+
echo "Checking commit message for AI attribution..."
|
|
8
|
+
|
|
9
|
+
# Block third-party AI tool attribution
|
|
10
|
+
if grep -qiE "(claude|anthropic|chatgpt|openai.*generated|copilot.*generated|co-authored-by:.*claude|co-authored-by:.*chatgpt|co-authored-by:.*copilot|generated with claude|generated with chatgpt|generated with.*https://claude\.com)" "$COMMIT_MSG_FILE"; then
|
|
11
|
+
echo "ERROR: Commit message contains FORBIDDEN third-party AI attribution!"
|
|
12
|
+
echo ""
|
|
13
|
+
echo "FORBIDDEN TERMS DETECTED:"
|
|
14
|
+
echo " - Claude, Anthropic, claude.com"
|
|
15
|
+
echo " - ChatGPT, OpenAI (as code author)"
|
|
16
|
+
echo " - Copilot, GitHub Copilot"
|
|
17
|
+
echo " - 'Generated with', 'Powered by' + third-party tools"
|
|
18
|
+
echo " - 'Co-Authored-By: Claude/ChatGPT/Copilot'"
|
|
19
|
+
echo ""
|
|
20
|
+
echo "See .ainative/git-rules.md for complete guidelines"
|
|
21
|
+
echo ""
|
|
22
|
+
exit 1
|
|
23
|
+
fi
|
|
24
|
+
|
|
25
|
+
echo "Commit message: PASS"
|
|
26
|
+
exit 0
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
# Install git hooks for file placement and commit message enforcement
|
|
3
|
+
# Run from project root: bash .claude/hooks/install-hooks.sh
|
|
4
|
+
|
|
5
|
+
set -e
|
|
6
|
+
|
|
7
|
+
echo "Installing git hooks..."
|
|
8
|
+
echo ""
|
|
9
|
+
|
|
10
|
+
# Determine which folder we're in (.ainative or .claude)
|
|
11
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
12
|
+
HOOKS_SOURCE="$SCRIPT_DIR"
|
|
13
|
+
|
|
14
|
+
# Check if we're in a git repository
|
|
15
|
+
if [ ! -d ".git" ]; then
|
|
16
|
+
echo "Error: Not in a git repository root"
|
|
17
|
+
echo " Run this script from your project root directory"
|
|
18
|
+
exit 1
|
|
19
|
+
fi
|
|
20
|
+
|
|
21
|
+
# Create .git/hooks directory if it doesn't exist
|
|
22
|
+
mkdir -p .git/hooks
|
|
23
|
+
|
|
24
|
+
# Install pre-commit hook
|
|
25
|
+
echo "Installing pre-commit hook..."
|
|
26
|
+
cp "$HOOKS_SOURCE/pre-commit" .git/hooks/pre-commit
|
|
27
|
+
chmod +x .git/hooks/pre-commit
|
|
28
|
+
echo "pre-commit hook installed"
|
|
29
|
+
|
|
30
|
+
# Install commit-msg hook
|
|
31
|
+
echo "Installing commit-msg hook..."
|
|
32
|
+
cp "$HOOKS_SOURCE/commit-msg" .git/hooks/commit-msg
|
|
33
|
+
chmod +x .git/hooks/commit-msg
|
|
34
|
+
echo "commit-msg hook installed"
|
|
35
|
+
|
|
36
|
+
echo ""
|
|
37
|
+
echo "All hooks installed successfully!"
|
|
38
|
+
echo ""
|
|
39
|
+
echo "Enforcement active:"
|
|
40
|
+
echo " - File placement validation (pre-commit)"
|
|
41
|
+
echo " - Third-party attribution blocking (commit-msg)"
|
|
42
|
+
echo ""
|
|
43
|
+
echo "Test with:"
|
|
44
|
+
echo " touch test.md && git add test.md && git commit -m 'test'"
|
|
45
|
+
echo " (Should be blocked)"
|
|
46
|
+
echo ""
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
# File Placement Pre-commit Hook
|
|
3
|
+
# Enforces file placement rules
|
|
4
|
+
|
|
5
|
+
echo "Checking file placement rules..."
|
|
6
|
+
|
|
7
|
+
# Check for .md files in root (except README.md and CLAUDE.md)
|
|
8
|
+
VIOLATIONS=$(git diff --cached --name-only --diff-filter=A | grep -E '^[^/]+\.md$' | grep -v -E '^(README\.md|CLAUDE\.md)$' || true)
|
|
9
|
+
if [ ! -z "$VIOLATIONS" ]; then
|
|
10
|
+
echo "BLOCKED: Attempting to add .md files to root directory:"
|
|
11
|
+
echo "$VIOLATIONS"
|
|
12
|
+
echo ""
|
|
13
|
+
echo "Per file-placement rules:"
|
|
14
|
+
echo "Only README.md and CLAUDE.md are allowed in root."
|
|
15
|
+
echo ""
|
|
16
|
+
echo "Move to appropriate docs/ subdirectory:"
|
|
17
|
+
echo " - Product docs -> docs/product/"
|
|
18
|
+
echo " - Planning docs -> docs/planning/"
|
|
19
|
+
echo " - API docs -> docs/api/"
|
|
20
|
+
echo " - Implementation -> docs/reports/"
|
|
21
|
+
echo " - Issues -> docs/issues/"
|
|
22
|
+
echo " - Backend docs -> docs/backend/"
|
|
23
|
+
echo ""
|
|
24
|
+
exit 1
|
|
25
|
+
fi
|
|
26
|
+
|
|
27
|
+
# Check for .sh files in root
|
|
28
|
+
VIOLATIONS=$(git diff --cached --name-only --diff-filter=A | grep -E '^[^/]+\.sh$' || true)
|
|
29
|
+
if [ ! -z "$VIOLATIONS" ]; then
|
|
30
|
+
echo "BLOCKED: Attempting to add .sh files to root directory:"
|
|
31
|
+
echo "$VIOLATIONS"
|
|
32
|
+
echo ""
|
|
33
|
+
echo "All scripts must be in scripts/ directory"
|
|
34
|
+
echo ""
|
|
35
|
+
exit 1
|
|
36
|
+
fi
|
|
37
|
+
|
|
38
|
+
# Check for .sh files in backend (except start.sh)
|
|
39
|
+
VIOLATIONS=$(git diff --cached --name-only --diff-filter=A | grep -E '^backend/.*\.sh$' | grep -v 'backend/start.sh' || true)
|
|
40
|
+
if [ ! -z "$VIOLATIONS" ]; then
|
|
41
|
+
echo "BLOCKED: Attempting to add .sh files to backend/ (except start.sh):"
|
|
42
|
+
echo "$VIOLATIONS"
|
|
43
|
+
echo ""
|
|
44
|
+
echo "All scripts must be in scripts/ directory"
|
|
45
|
+
echo "Exception: backend/start.sh only"
|
|
46
|
+
echo ""
|
|
47
|
+
exit 1
|
|
48
|
+
fi
|
|
49
|
+
|
|
50
|
+
# Check for .md files in src/backend/
|
|
51
|
+
VIOLATIONS=$(git diff --cached --name-only --diff-filter=A | grep -E '^src/backend/.*\.md$' || true)
|
|
52
|
+
if [ ! -z "$VIOLATIONS" ]; then
|
|
53
|
+
echo "BLOCKED: Attempting to add .md files to src/backend/:"
|
|
54
|
+
echo "$VIOLATIONS"
|
|
55
|
+
echo ""
|
|
56
|
+
echo "Documentation must be in docs/ directory"
|
|
57
|
+
echo ""
|
|
58
|
+
exit 1
|
|
59
|
+
fi
|
|
60
|
+
|
|
61
|
+
echo "File placement rules: PASS"
|
|
62
|
+
exit 0
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
{
|
|
2
|
+
"mcpServers": {
|
|
3
|
+
"github": {
|
|
4
|
+
"command": "npx",
|
|
5
|
+
"args": [
|
|
6
|
+
"-y",
|
|
7
|
+
"@modelcontextprotocol/server-github"
|
|
8
|
+
],
|
|
9
|
+
"env": {
|
|
10
|
+
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
|
|
11
|
+
}
|
|
12
|
+
},
|
|
13
|
+
"sequential-thinking": {
|
|
14
|
+
"command": "npx",
|
|
15
|
+
"args": [
|
|
16
|
+
"-y",
|
|
17
|
+
"@modelcontextprotocol/server-sequential-thinking"
|
|
18
|
+
]
|
|
19
|
+
},
|
|
20
|
+
"filesystem": {
|
|
21
|
+
"command": "npx",
|
|
22
|
+
"args": [
|
|
23
|
+
"-y",
|
|
24
|
+
"@modelcontextprotocol/server-filesystem"
|
|
25
|
+
],
|
|
26
|
+
"args": [
|
|
27
|
+
"/path/to/your/project"
|
|
28
|
+
]
|
|
29
|
+
}
|
|
30
|
+
}
|
|
31
|
+
}
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
{
|
|
2
|
+
"permissions": {
|
|
3
|
+
"allow": [
|
|
4
|
+
"Bash(curl:*)",
|
|
5
|
+
"Bash(git:*)",
|
|
6
|
+
"Bash(ls:*)",
|
|
7
|
+
"Bash(cat:*)",
|
|
8
|
+
"Bash(find:*)",
|
|
9
|
+
"Bash(npm:*)",
|
|
10
|
+
"Bash(npx:*)",
|
|
11
|
+
"Bash(bun:*)",
|
|
12
|
+
"Bash(node:*)",
|
|
13
|
+
"Bash(python:*)",
|
|
14
|
+
"Bash(python3:*)",
|
|
15
|
+
"Bash(gh:*)",
|
|
16
|
+
"Bash(tree:*)",
|
|
17
|
+
"Bash(chmod:*)",
|
|
18
|
+
"Bash(mkdir:*)",
|
|
19
|
+
"Bash(cp:*)",
|
|
20
|
+
"Bash(mv:*)"
|
|
21
|
+
],
|
|
22
|
+
"deny": []
|
|
23
|
+
}
|
|
24
|
+
}
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ci-cd-compliance
|
|
3
|
+
description: CI/CD pipeline requirements and deployment standards. Use when (1) Setting up CI/CD pipelines, (2) Debugging CI failures, (3) Configuring deployment workflows, (4) Managing staging/production releases, (5) Investigating build failures. Covers CI gate requirements, merge policies, auto-deploy to staging, production approval process.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# CI/CD Compliance Rules
|
|
7
|
+
|
|
8
|
+
## CI Gates Sequence
|
|
9
|
+
|
|
10
|
+
**install -> lint/format -> typecheck -> unit -> integration -> (optional e2e) -> package**
|
|
11
|
+
|
|
12
|
+
## Merge Policy
|
|
13
|
+
|
|
14
|
+
* **Merge only if green**
|
|
15
|
+
* Auto-deploy to **staging** on merge
|
|
16
|
+
* Production requires tag/approval
|
|
17
|
+
|
|
18
|
+
## CI Failure Handling
|
|
19
|
+
|
|
20
|
+
When CI fails:
|
|
21
|
+
1. **Explain root cause** in PR comment
|
|
22
|
+
2. **Include the fix** in the same PR when feasible
|
|
23
|
+
3. Don't merge until all gates pass
|
|
24
|
+
|
|
25
|
+
## IDE Integration
|
|
26
|
+
|
|
27
|
+
* Use built-in code actions and terminal to run tests/linters
|
|
28
|
+
* Prefer **unified diffs** in responses so changes are patchable across IDEs
|
|
29
|
+
* Attach artifacts (test output, screenshots, logs) whenever you assert a claim
|
|
30
|
+
|
|
31
|
+
## Reference Files
|
|
32
|
+
|
|
33
|
+
See `references/pipeline-requirements.md` for detailed CI configuration, gate definitions, and failure debugging guide.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: code-quality
|
|
3
|
+
description: Coding style standards, security guidelines, and accessibility requirements. Use when (1) Writing new code, (2) Reviewing code for style/security, (3) Implementing UI/UX features, (4) Addressing security concerns, (5) Ensuring accessibility compliance. Covers naming conventions, formatting, security best practices (no secrets/PII), accessibility standards (semantic HTML, keyboard nav), and responsive design.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Code Quality Standards
|
|
7
|
+
|
|
8
|
+
## Coding Style
|
|
9
|
+
|
|
10
|
+
* **Naming:** camelCase for vars/functions; PascalCase for classes/types
|
|
11
|
+
* **Formatting:** 4-space indentation; target <=80 chars (wrap thoughtfully)
|
|
12
|
+
* **Comments:** Meaningful, current; delete stale comments
|
|
13
|
+
* **Security:** Never log secrets/PII; validate inputs; least privilege by default
|
|
14
|
+
* **Errors/Logs:** Explicit error types; structured logs by level; actionable messages
|
|
15
|
+
|
|
16
|
+
## Accessibility & UX Quality
|
|
17
|
+
|
|
18
|
+
* Favor semantic roles/labels; keyboard nav and focus order must work
|
|
19
|
+
* Include responsive checks at **375, 768, 1024, 1440** with notes/screenshots
|
|
20
|
+
* Use deterministic test IDs; avoid brittle CSS/XPath
|
|
21
|
+
|
|
22
|
+
## Security & Compliance Guardrails
|
|
23
|
+
|
|
24
|
+
* No real credentials in code, tests, or screenshots
|
|
25
|
+
* Use test accounts/fixtures; redact secrets
|
|
26
|
+
* Follow least-privilege and input validation
|
|
27
|
+
* Document threat considerations in PR when relevant
|
|
28
|
+
|
|
29
|
+
## Reference Files
|
|
30
|
+
|
|
31
|
+
See `references/coding-style.md` for detailed style guide, formatting rules, comment standards.
|
|
32
|
+
|
|
33
|
+
See `references/security-checklist.md` for security validation checklist, threat modeling, PII handling.
|
|
34
|
+
|
|
35
|
+
See `references/accessibility-standards.md` for WCAG compliance, semantic HTML patterns, keyboard nav testing.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: file-placement
|
|
3
|
+
description: Enforces ZERO TOLERANCE file placement rules for documentation and scripts. Use when (1) Creating any .md file, (2) Creating any .sh script, (3) Organizing documentation, (4) Writing guides or reports, (5) Adding utility scripts. CRITICAL RULES - NEVER create .md files in root directories (except README.md, CLAUDE.md), NEVER create .sh scripts in backend (except start.sh), ALL documentation goes in docs/ subfolders, ALL scripts go in scripts/ folder.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# File Placement Rules
|
|
7
|
+
|
|
8
|
+
## ZERO TOLERANCE FILE PLACEMENT
|
|
9
|
+
|
|
10
|
+
### STRICT RULES
|
|
11
|
+
|
|
12
|
+
* **FORBIDDEN:** Creating .md files in project root (except README.md, CLAUDE.md)
|
|
13
|
+
* **FORBIDDEN:** Creating .md files in src/backend/ (except README.md)
|
|
14
|
+
* **FORBIDDEN:** Creating scripts (.sh) in src/backend/ (except start.sh)
|
|
15
|
+
|
|
16
|
+
### REQUIRED LOCATIONS
|
|
17
|
+
|
|
18
|
+
## Backend Documentation -> `docs/`
|
|
19
|
+
|
|
20
|
+
* **Issues/Bugs:** `docs/issues/ISSUE_*.md`, `docs/issues/BUG_*.md`, `docs/issues/ROOT_CAUSE_*.md`
|
|
21
|
+
* **Testing/QA:** `docs/testing/*_TEST*.md`, `docs/testing/QA_*.md`
|
|
22
|
+
* **API Documentation:** `docs/api/API_*.md`, `docs/api/*_ENDPOINTS*.md`
|
|
23
|
+
* **Implementation Reports:** `docs/reports/*_IMPLEMENTATION*.md`, `docs/reports/*_SUMMARY.md`
|
|
24
|
+
* **Deployment:** `docs/deployment/DEPLOYMENT_*.md`, `docs/deployment/RAILWAY_*.md`
|
|
25
|
+
* **Quick References:** `docs/quick-reference/*_QUICK_*.md`, `docs/quick-reference/*_REFERENCE.md`
|
|
26
|
+
* **Development Guides:** `docs/development-guides/CODING_*.md`, `docs/development-guides/*_GUIDE.md`
|
|
27
|
+
* **Planning:** `docs/planning/PRD_*.md`, `docs/planning/BACKLOG*.md`
|
|
28
|
+
|
|
29
|
+
## Scripts -> `scripts/`
|
|
30
|
+
|
|
31
|
+
* **ALL test scripts:** `scripts/test_*.sh`
|
|
32
|
+
* **ALL migration scripts:** `scripts/*_migration.sh`
|
|
33
|
+
* **ALL monitoring scripts:** `scripts/monitor_*.sh`
|
|
34
|
+
* **ALL utility scripts:** `scripts/*.sh`
|
|
35
|
+
|
|
36
|
+
## ENFORCEMENT WORKFLOW
|
|
37
|
+
|
|
38
|
+
Before creating ANY .md file or .sh script, you MUST:
|
|
39
|
+
|
|
40
|
+
1. Check if you're creating it in a root directory
|
|
41
|
+
2. If yes, STOP and use the appropriate docs/ or scripts/ subfolder
|
|
42
|
+
3. Choose the correct category based on filename patterns above
|
|
43
|
+
4. Create in the correct location FIRST TIME, not in root then move later
|
|
44
|
+
|
|
45
|
+
## VIOLATION CONSEQUENCES
|
|
46
|
+
|
|
47
|
+
Creating documentation in root directories causes:
|
|
48
|
+
|
|
49
|
+
* Project clutter and disorganization
|
|
50
|
+
* Wasted time reorganizing files
|
|
51
|
+
* Inconsistent documentation structure
|
|
52
|
+
* Developer frustration
|
|
53
|
+
* Loss of findability for important docs
|
|
54
|
+
|
|
55
|
+
**THIS IS A ZERO-TOLERANCE RULE. ALWAYS use docs/ or scripts/ subfolders.**
|
|
56
|
+
|
|
57
|
+
## Reference Files
|
|
58
|
+
|
|
59
|
+
See `references/directory-mapping.md` for complete mapping table of filename patterns to required directory locations.
|