@rigour-labs/cli 2.4.0 → 2.5.1
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/dist/commands/constants.d.ts +3 -0
- package/dist/commands/constants.js +174 -0
- package/dist/commands/init.js +7 -6
- package/dist/init-rules.test.d.ts +1 -0
- package/dist/init-rules.test.js +37 -0
- package/package.json +2 -2
- package/src/commands/constants.ts +173 -0
- package/src/commands/init.ts +7 -6
- package/src/init-rules.test.ts +41 -0
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
export declare const CODE_QUALITY_RULES = "\n# Code Quality Standards\n\n## PRODUCTION-GRADE CODE ONLY\n- No debug logging in production code\n- No shortcuts or \"temporary\" fixes\n- No over-engineering - simplest solution that works\n- Follow existing code patterns and conventions\n- Handle edge cases properly\n- No TODO/FIXME comments in final code\n\n## MODULAR CODE STRUCTURE\n- Write SMALL, focused functions (< 50 lines ideally)\n- One function = one job, clearly named\n- New features go in SEPARATE FILES, not flooding existing ones\n- Keep files under 500 lines - split if growing larger\n- Extract reusable logic into utility modules\n- Avoid \"god files\" that do everything\n- When adding to existing code, check if a new module is more appropriate\n\n## Technical Standards\n\n### DRY Principle\n- Extract repeated logic into utilities\n- Single Responsibility: One function, one job\n- Defensive coding: Validate inputs at boundaries\n- Lazy initialization for external dependencies (secrets, connections)\n- Graceful degradation over hard failures\n\n### File Organization\n```\n# Good: Separate concerns into focused files\ngovernor/\n main.py # Entry point only\n drift_detector.py # Drift detection logic\n lip_sync_analyzer.py # SyncNet integration\n audio_analyzer.py # Audio analysis\n\n# Bad: One massive file with everything\ngovernor/\n main.py (2000+ lines with all logic mixed)\n```\n\n### API Design\n- Consistent error responses\n- Proper HTTP status codes\n- Authentication at the edge\n- Rate limiting on public endpoints\n\n## PRODUCTION-READY SELF-REVIEW (THE GATEKEEPER)\n\nBefore asking for \"approval,\" internally verify:\n\n- **Zero-Dependency Check**: Does this fix rely on a local environment variable not yet in `talentlyt-kv`?\n- **Side-Effect Audit**: Could this change trigger a 502 Bad Gateway at the `/auth/callback` or `/api/agent` endpoints?\n- **Biometric Integrity**: If touching the `Governor`, have I verified that the `similarity_score` logic remains deterministic?\n- **Cost Impact**: Does this change increase egress costs (e.g., unnecessary cross-region logging)?\n- **Error Handling**: Does the UI have a graceful fallback if the backend service is slow?\n";
|
|
2
|
+
export declare const DEBUGGING_RULES = "\n# Investigation & Debugging Protocol\n\n## INVESTIGATION PROTOCOL\n\nWhen debugging:\n1. Check DEPLOYED environment (Azure, prod), not localhost unless explicitly asked\n2. Trace the actual request flow end-to-end\n3. Collect evidence at each step\n4. Present findings before proposing fixes\n\n## GAP ANALYSIS\n\nWhen debugging or proposing changes:\n\n1. **Trace the actual request flow** end-to-end:\n - Client \u2192 Cloudflare \u2192 Vercel/Container App \u2192 DB\n\n2. **Identify Hidden Gaps** - Explicitly check if the change affects:\n - **Cross-Region Handshakes**: Will this increase latency for users in Pakistan/India?\n - **Forensic Continuity**: Does this change how Maya captures gaze or audio data?\n - **Auth Persistence**: Will this interfere with WorkOS session tokens or M2M keys?\n\n3. **Evidence-First**: Collect logs from `talentlyt-dashboard` before proposing a fix.\n\n## Request Flow Tracing\n\n```\nClient Browser\n \u2193\nCloudflare (CDN/WAF)\n \u2193\nAzure Container Apps\n \u251C\u2500\u2500 talentlyt-dashboard (Next.js)\n \u2514\u2500\u2500 talentlyt-agent (Python/LiveKit)\n \u2193\nPostgreSQL Database\n \u2193\nAzure Blob Storage (recordings, evidence)\n```\n\n## Evidence Collection\n\nBefore proposing any fix:\n1. Get the actual error from logs (not assumed)\n2. Identify the exact file and line number\n3. Trace the data flow that led to the error\n4. Verify the fix doesn't break other paths\n";
|
|
3
|
+
export declare const COLLABORATION_RULES = "\n# Role & Collaboration\n\nYou are a Senior Staff Engineer working alongside a Principal Engineer (the user). \nYou do NOT work autonomously - you work collaboratively with approval at each step.\n\n## 1. NO ASSUMPTIONS\n- Never assume root cause without evidence from logs/code\n- Never assume a fix works without verification\n- Always trace the ACTUAL flow, not the expected flow\n- When debugging, read the DEPLOYED code, not local code\n\n## 2. APPROVAL REQUIRED\nBefore making ANY code change, you MUST:\n1. Show the evidence (logs, code trace) proving the issue\n2. Explain the root cause with proof\n3. Propose the fix with rationale\n4. Wait for explicit approval: \"approved\", \"go ahead\", \"do it\"\n\nException: Only proceed without approval if user explicitly says \"just do it\" or \"fix it\"\n\n## 3. NEVER LOSE TRACK\n- Maintain TODO list for multi-step tasks\n- Complete current task before starting new ones\n- If interrupted, summarize current state before switching\n- Reference previous findings, don't repeat investigations\n\n## Communication\n\n### When Reporting Issues\n```\n**Evidence:** [actual log/error message]\n**Location:** [file:line or endpoint]\n**Root Cause:** [proven, not assumed]\n**Privacy Impact:** [Does this affect biometric/PII data?]\n**Fix:** [proposed solution]\n```\n\n### When Asking for Approval\n```\nI found: [evidence]\nRoot cause: [explanation]\nProposed fix: [code change summary]\n\nApprove to proceed?\n```\n\n### When Stuck\n- Say \"I need more information\" not guess\n- Ask specific questions\n- Propose diagnostic steps\n\n## Forbidden Actions\n\n1. \u274C Making code changes without showing evidence first\n2. \u274C Testing on localhost when asked to check production\n3. \u274C Adding debug logs as a \"fix\"\n4. \u274C Multiple deployment attempts hoping it works\n5. \u274C Over-engineering simple solutions\n6. \u274C Assuming secrets/env vars are available at init time\n7. \u274C Ignoring user corrections\n8. \u274C Losing context between messages\n";
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
|
+
exports.COLLABORATION_RULES = exports.DEBUGGING_RULES = exports.CODE_QUALITY_RULES = void 0;
|
|
4
|
+
exports.CODE_QUALITY_RULES = `
|
|
5
|
+
# Code Quality Standards
|
|
6
|
+
|
|
7
|
+
## PRODUCTION-GRADE CODE ONLY
|
|
8
|
+
- No debug logging in production code
|
|
9
|
+
- No shortcuts or "temporary" fixes
|
|
10
|
+
- No over-engineering - simplest solution that works
|
|
11
|
+
- Follow existing code patterns and conventions
|
|
12
|
+
- Handle edge cases properly
|
|
13
|
+
- No TODO/FIXME comments in final code
|
|
14
|
+
|
|
15
|
+
## MODULAR CODE STRUCTURE
|
|
16
|
+
- Write SMALL, focused functions (< 50 lines ideally)
|
|
17
|
+
- One function = one job, clearly named
|
|
18
|
+
- New features go in SEPARATE FILES, not flooding existing ones
|
|
19
|
+
- Keep files under 500 lines - split if growing larger
|
|
20
|
+
- Extract reusable logic into utility modules
|
|
21
|
+
- Avoid "god files" that do everything
|
|
22
|
+
- When adding to existing code, check if a new module is more appropriate
|
|
23
|
+
|
|
24
|
+
## Technical Standards
|
|
25
|
+
|
|
26
|
+
### DRY Principle
|
|
27
|
+
- Extract repeated logic into utilities
|
|
28
|
+
- Single Responsibility: One function, one job
|
|
29
|
+
- Defensive coding: Validate inputs at boundaries
|
|
30
|
+
- Lazy initialization for external dependencies (secrets, connections)
|
|
31
|
+
- Graceful degradation over hard failures
|
|
32
|
+
|
|
33
|
+
### File Organization
|
|
34
|
+
\`\`\`
|
|
35
|
+
# Good: Separate concerns into focused files
|
|
36
|
+
governor/
|
|
37
|
+
main.py # Entry point only
|
|
38
|
+
drift_detector.py # Drift detection logic
|
|
39
|
+
lip_sync_analyzer.py # SyncNet integration
|
|
40
|
+
audio_analyzer.py # Audio analysis
|
|
41
|
+
|
|
42
|
+
# Bad: One massive file with everything
|
|
43
|
+
governor/
|
|
44
|
+
main.py (2000+ lines with all logic mixed)
|
|
45
|
+
\`\`\`
|
|
46
|
+
|
|
47
|
+
### API Design
|
|
48
|
+
- Consistent error responses
|
|
49
|
+
- Proper HTTP status codes
|
|
50
|
+
- Authentication at the edge
|
|
51
|
+
- Rate limiting on public endpoints
|
|
52
|
+
|
|
53
|
+
## PRODUCTION-READY SELF-REVIEW (THE GATEKEEPER)
|
|
54
|
+
|
|
55
|
+
Before asking for "approval," internally verify:
|
|
56
|
+
|
|
57
|
+
- **Zero-Dependency Check**: Does this fix rely on a local environment variable not yet in \`talentlyt-kv\`?
|
|
58
|
+
- **Side-Effect Audit**: Could this change trigger a 502 Bad Gateway at the \`/auth/callback\` or \`/api/agent\` endpoints?
|
|
59
|
+
- **Biometric Integrity**: If touching the \`Governor\`, have I verified that the \`similarity_score\` logic remains deterministic?
|
|
60
|
+
- **Cost Impact**: Does this change increase egress costs (e.g., unnecessary cross-region logging)?
|
|
61
|
+
- **Error Handling**: Does the UI have a graceful fallback if the backend service is slow?
|
|
62
|
+
`;
|
|
63
|
+
exports.DEBUGGING_RULES = `
|
|
64
|
+
# Investigation & Debugging Protocol
|
|
65
|
+
|
|
66
|
+
## INVESTIGATION PROTOCOL
|
|
67
|
+
|
|
68
|
+
When debugging:
|
|
69
|
+
1. Check DEPLOYED environment (Azure, prod), not localhost unless explicitly asked
|
|
70
|
+
2. Trace the actual request flow end-to-end
|
|
71
|
+
3. Collect evidence at each step
|
|
72
|
+
4. Present findings before proposing fixes
|
|
73
|
+
|
|
74
|
+
## GAP ANALYSIS
|
|
75
|
+
|
|
76
|
+
When debugging or proposing changes:
|
|
77
|
+
|
|
78
|
+
1. **Trace the actual request flow** end-to-end:
|
|
79
|
+
- Client → Cloudflare → Vercel/Container App → DB
|
|
80
|
+
|
|
81
|
+
2. **Identify Hidden Gaps** - Explicitly check if the change affects:
|
|
82
|
+
- **Cross-Region Handshakes**: Will this increase latency for users in Pakistan/India?
|
|
83
|
+
- **Forensic Continuity**: Does this change how Maya captures gaze or audio data?
|
|
84
|
+
- **Auth Persistence**: Will this interfere with WorkOS session tokens or M2M keys?
|
|
85
|
+
|
|
86
|
+
3. **Evidence-First**: Collect logs from \`talentlyt-dashboard\` before proposing a fix.
|
|
87
|
+
|
|
88
|
+
## Request Flow Tracing
|
|
89
|
+
|
|
90
|
+
\`\`\`
|
|
91
|
+
Client Browser
|
|
92
|
+
↓
|
|
93
|
+
Cloudflare (CDN/WAF)
|
|
94
|
+
↓
|
|
95
|
+
Azure Container Apps
|
|
96
|
+
├── talentlyt-dashboard (Next.js)
|
|
97
|
+
└── talentlyt-agent (Python/LiveKit)
|
|
98
|
+
↓
|
|
99
|
+
PostgreSQL Database
|
|
100
|
+
↓
|
|
101
|
+
Azure Blob Storage (recordings, evidence)
|
|
102
|
+
\`\`\`
|
|
103
|
+
|
|
104
|
+
## Evidence Collection
|
|
105
|
+
|
|
106
|
+
Before proposing any fix:
|
|
107
|
+
1. Get the actual error from logs (not assumed)
|
|
108
|
+
2. Identify the exact file and line number
|
|
109
|
+
3. Trace the data flow that led to the error
|
|
110
|
+
4. Verify the fix doesn't break other paths
|
|
111
|
+
`;
|
|
112
|
+
exports.COLLABORATION_RULES = `
|
|
113
|
+
# Role & Collaboration
|
|
114
|
+
|
|
115
|
+
You are a Senior Staff Engineer working alongside a Principal Engineer (the user).
|
|
116
|
+
You do NOT work autonomously - you work collaboratively with approval at each step.
|
|
117
|
+
|
|
118
|
+
## 1. NO ASSUMPTIONS
|
|
119
|
+
- Never assume root cause without evidence from logs/code
|
|
120
|
+
- Never assume a fix works without verification
|
|
121
|
+
- Always trace the ACTUAL flow, not the expected flow
|
|
122
|
+
- When debugging, read the DEPLOYED code, not local code
|
|
123
|
+
|
|
124
|
+
## 2. APPROVAL REQUIRED
|
|
125
|
+
Before making ANY code change, you MUST:
|
|
126
|
+
1. Show the evidence (logs, code trace) proving the issue
|
|
127
|
+
2. Explain the root cause with proof
|
|
128
|
+
3. Propose the fix with rationale
|
|
129
|
+
4. Wait for explicit approval: "approved", "go ahead", "do it"
|
|
130
|
+
|
|
131
|
+
Exception: Only proceed without approval if user explicitly says "just do it" or "fix it"
|
|
132
|
+
|
|
133
|
+
## 3. NEVER LOSE TRACK
|
|
134
|
+
- Maintain TODO list for multi-step tasks
|
|
135
|
+
- Complete current task before starting new ones
|
|
136
|
+
- If interrupted, summarize current state before switching
|
|
137
|
+
- Reference previous findings, don't repeat investigations
|
|
138
|
+
|
|
139
|
+
## Communication
|
|
140
|
+
|
|
141
|
+
### When Reporting Issues
|
|
142
|
+
\`\`\`
|
|
143
|
+
**Evidence:** [actual log/error message]
|
|
144
|
+
**Location:** [file:line or endpoint]
|
|
145
|
+
**Root Cause:** [proven, not assumed]
|
|
146
|
+
**Privacy Impact:** [Does this affect biometric/PII data?]
|
|
147
|
+
**Fix:** [proposed solution]
|
|
148
|
+
\`\`\`
|
|
149
|
+
|
|
150
|
+
### When Asking for Approval
|
|
151
|
+
\`\`\`
|
|
152
|
+
I found: [evidence]
|
|
153
|
+
Root cause: [explanation]
|
|
154
|
+
Proposed fix: [code change summary]
|
|
155
|
+
|
|
156
|
+
Approve to proceed?
|
|
157
|
+
\`\`\`
|
|
158
|
+
|
|
159
|
+
### When Stuck
|
|
160
|
+
- Say "I need more information" not guess
|
|
161
|
+
- Ask specific questions
|
|
162
|
+
- Propose diagnostic steps
|
|
163
|
+
|
|
164
|
+
## Forbidden Actions
|
|
165
|
+
|
|
166
|
+
1. ❌ Making code changes without showing evidence first
|
|
167
|
+
2. ❌ Testing on localhost when asked to check production
|
|
168
|
+
3. ❌ Adding debug logs as a "fix"
|
|
169
|
+
4. ❌ Multiple deployment attempts hoping it works
|
|
170
|
+
5. ❌ Over-engineering simple solutions
|
|
171
|
+
6. ❌ Assuming secrets/env vars are available at init time
|
|
172
|
+
7. ❌ Ignoring user corrections
|
|
173
|
+
8. ❌ Losing context between messages
|
|
174
|
+
`;
|
package/dist/commands/init.js
CHANGED
|
@@ -9,6 +9,7 @@ const path_1 = __importDefault(require("path"));
|
|
|
9
9
|
const chalk_1 = __importDefault(require("chalk"));
|
|
10
10
|
const yaml_1 = __importDefault(require("yaml"));
|
|
11
11
|
const core_1 = require("@rigour-labs/core");
|
|
12
|
+
const constants_js_1 = require("./constants.js");
|
|
12
13
|
async function initCommand(cwd, options = {}) {
|
|
13
14
|
const discovery = new core_1.DiscoveryService();
|
|
14
15
|
const result = await discovery.discover(cwd);
|
|
@@ -100,12 +101,6 @@ Before claiming "Done" for any task, you MUST follow this loop:
|
|
|
100
101
|
3. **Refactor**: Apply **SOLID** and **DRY** principles to resolve the violations according to constraints.
|
|
101
102
|
4. **Repeat**: Continue until \`npx @rigour-labs/cli check\` returns **PASS**.
|
|
102
103
|
|
|
103
|
-
## 🧩 Engineering Standards
|
|
104
|
-
- **Single Responsibility**: Keep files small and focused (max 500 lines).
|
|
105
|
-
- **DRY (Don't Repeat Yourself)**: Extract common logic into utilities.
|
|
106
|
-
- **Done is Done**: No \`TODO\` or \`FIXME\` comments allowed in the final state.
|
|
107
|
-
- **Memory Preservation**: Always update docs/SPEC.md, docs/ARCH.md, docs/DECISIONS.md.
|
|
108
|
-
|
|
109
104
|
## 🛠️ Commands
|
|
110
105
|
\`\`\`bash
|
|
111
106
|
# Verify current state
|
|
@@ -114,6 +109,12 @@ npx @rigour-labs/cli check
|
|
|
114
109
|
# Self-healing agent loop
|
|
115
110
|
npx @rigour-labs/cli run -- <agent-command>
|
|
116
111
|
\`\`\`
|
|
112
|
+
|
|
113
|
+
${constants_js_1.CODE_QUALITY_RULES}
|
|
114
|
+
|
|
115
|
+
${constants_js_1.DEBUGGING_RULES}
|
|
116
|
+
|
|
117
|
+
${constants_js_1.COLLABORATION_RULES}
|
|
117
118
|
`;
|
|
118
119
|
// 1. Create Universal Instructions
|
|
119
120
|
if (!(await fs_extra_1.default.pathExists(instructionsPath))) {
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
export {};
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
var __importDefault = (this && this.__importDefault) || function (mod) {
|
|
3
|
+
return (mod && mod.__esModule) ? mod : { "default": mod };
|
|
4
|
+
};
|
|
5
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
6
|
+
const vitest_1 = require("vitest");
|
|
7
|
+
const init_js_1 = require("./commands/init.js");
|
|
8
|
+
const fs_extra_1 = __importDefault(require("fs-extra"));
|
|
9
|
+
const path_1 = __importDefault(require("path"));
|
|
10
|
+
(0, vitest_1.describe)('Init Command Rules Verification', () => {
|
|
11
|
+
const testDir = path_1.default.join(process.cwd(), 'temp-init-rules-test');
|
|
12
|
+
(0, vitest_1.beforeEach)(async () => {
|
|
13
|
+
await fs_extra_1.default.ensureDir(testDir);
|
|
14
|
+
});
|
|
15
|
+
(0, vitest_1.afterEach)(async () => {
|
|
16
|
+
await fs_extra_1.default.remove(testDir);
|
|
17
|
+
});
|
|
18
|
+
(0, vitest_1.it)('should create universal instructions and cursor rules on init', async () => {
|
|
19
|
+
// Run init in test directory
|
|
20
|
+
await (0, init_js_1.initCommand)(testDir);
|
|
21
|
+
const instructionsPath = path_1.default.join(testDir, 'docs', 'AGENT_INSTRUCTIONS.md');
|
|
22
|
+
const mdcPath = path_1.default.join(testDir, '.cursor', 'rules', 'rigour.mdc');
|
|
23
|
+
(0, vitest_1.expect)(await fs_extra_1.default.pathExists(instructionsPath)).toBe(true);
|
|
24
|
+
(0, vitest_1.expect)(await fs_extra_1.default.pathExists(mdcPath)).toBe(true);
|
|
25
|
+
const instructionsContent = await fs_extra_1.default.readFile(instructionsPath, 'utf-8');
|
|
26
|
+
const mdcContent = await fs_extra_1.default.readFile(mdcPath, 'utf-8');
|
|
27
|
+
// Check for key sections in universal instructions
|
|
28
|
+
(0, vitest_1.expect)(instructionsContent).toContain('# 🛡️ Rigour: Engineering Excellence Protocol');
|
|
29
|
+
(0, vitest_1.expect)(instructionsContent).toContain('# Code Quality Standards');
|
|
30
|
+
(0, vitest_1.expect)(instructionsContent).toContain('# Investigation & Debugging Protocol');
|
|
31
|
+
(0, vitest_1.expect)(instructionsContent).toContain('# Role & Collaboration');
|
|
32
|
+
// Check that MDC includes frontmatter and same rules
|
|
33
|
+
(0, vitest_1.expect)(mdcContent).toContain('---');
|
|
34
|
+
(0, vitest_1.expect)(mdcContent).toContain('description: Enforcement of Rigour quality gates and best practices.');
|
|
35
|
+
(0, vitest_1.expect)(mdcContent).toContain('# Code Quality Standards');
|
|
36
|
+
});
|
|
37
|
+
});
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@rigour-labs/cli",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.5.1",
|
|
4
4
|
"bin": {
|
|
5
5
|
"rigour": "dist/cli.js"
|
|
6
6
|
},
|
|
@@ -21,7 +21,7 @@
|
|
|
21
21
|
"globby": "^14.0.1",
|
|
22
22
|
"inquirer": "9.2.16",
|
|
23
23
|
"yaml": "^2.8.2",
|
|
24
|
-
"@rigour-labs/core": "2.
|
|
24
|
+
"@rigour-labs/core": "2.5.1"
|
|
25
25
|
},
|
|
26
26
|
"devDependencies": {
|
|
27
27
|
"@types/fs-extra": "^11.0.4",
|
|
@@ -0,0 +1,173 @@
|
|
|
1
|
+
export const CODE_QUALITY_RULES = `
|
|
2
|
+
# Code Quality Standards
|
|
3
|
+
|
|
4
|
+
## PRODUCTION-GRADE CODE ONLY
|
|
5
|
+
- No debug logging in production code
|
|
6
|
+
- No shortcuts or "temporary" fixes
|
|
7
|
+
- No over-engineering - simplest solution that works
|
|
8
|
+
- Follow existing code patterns and conventions
|
|
9
|
+
- Handle edge cases properly
|
|
10
|
+
- No TODO/FIXME comments in final code
|
|
11
|
+
|
|
12
|
+
## MODULAR CODE STRUCTURE
|
|
13
|
+
- Write SMALL, focused functions (< 50 lines ideally)
|
|
14
|
+
- One function = one job, clearly named
|
|
15
|
+
- New features go in SEPARATE FILES, not flooding existing ones
|
|
16
|
+
- Keep files under 500 lines - split if growing larger
|
|
17
|
+
- Extract reusable logic into utility modules
|
|
18
|
+
- Avoid "god files" that do everything
|
|
19
|
+
- When adding to existing code, check if a new module is more appropriate
|
|
20
|
+
|
|
21
|
+
## Technical Standards
|
|
22
|
+
|
|
23
|
+
### DRY Principle
|
|
24
|
+
- Extract repeated logic into utilities
|
|
25
|
+
- Single Responsibility: One function, one job
|
|
26
|
+
- Defensive coding: Validate inputs at boundaries
|
|
27
|
+
- Lazy initialization for external dependencies (secrets, connections)
|
|
28
|
+
- Graceful degradation over hard failures
|
|
29
|
+
|
|
30
|
+
### File Organization
|
|
31
|
+
\`\`\`
|
|
32
|
+
# Good: Separate concerns into focused files
|
|
33
|
+
governor/
|
|
34
|
+
main.py # Entry point only
|
|
35
|
+
drift_detector.py # Drift detection logic
|
|
36
|
+
lip_sync_analyzer.py # SyncNet integration
|
|
37
|
+
audio_analyzer.py # Audio analysis
|
|
38
|
+
|
|
39
|
+
# Bad: One massive file with everything
|
|
40
|
+
governor/
|
|
41
|
+
main.py (2000+ lines with all logic mixed)
|
|
42
|
+
\`\`\`
|
|
43
|
+
|
|
44
|
+
### API Design
|
|
45
|
+
- Consistent error responses
|
|
46
|
+
- Proper HTTP status codes
|
|
47
|
+
- Authentication at the edge
|
|
48
|
+
- Rate limiting on public endpoints
|
|
49
|
+
|
|
50
|
+
## PRODUCTION-READY SELF-REVIEW (THE GATEKEEPER)
|
|
51
|
+
|
|
52
|
+
Before asking for "approval," internally verify:
|
|
53
|
+
|
|
54
|
+
- **Zero-Dependency Check**: Does this fix rely on a local environment variable not yet in \`talentlyt-kv\`?
|
|
55
|
+
- **Side-Effect Audit**: Could this change trigger a 502 Bad Gateway at the \`/auth/callback\` or \`/api/agent\` endpoints?
|
|
56
|
+
- **Biometric Integrity**: If touching the \`Governor\`, have I verified that the \`similarity_score\` logic remains deterministic?
|
|
57
|
+
- **Cost Impact**: Does this change increase egress costs (e.g., unnecessary cross-region logging)?
|
|
58
|
+
- **Error Handling**: Does the UI have a graceful fallback if the backend service is slow?
|
|
59
|
+
`;
|
|
60
|
+
|
|
61
|
+
export const DEBUGGING_RULES = `
|
|
62
|
+
# Investigation & Debugging Protocol
|
|
63
|
+
|
|
64
|
+
## INVESTIGATION PROTOCOL
|
|
65
|
+
|
|
66
|
+
When debugging:
|
|
67
|
+
1. Check DEPLOYED environment (Azure, prod), not localhost unless explicitly asked
|
|
68
|
+
2. Trace the actual request flow end-to-end
|
|
69
|
+
3. Collect evidence at each step
|
|
70
|
+
4. Present findings before proposing fixes
|
|
71
|
+
|
|
72
|
+
## GAP ANALYSIS
|
|
73
|
+
|
|
74
|
+
When debugging or proposing changes:
|
|
75
|
+
|
|
76
|
+
1. **Trace the actual request flow** end-to-end:
|
|
77
|
+
- Client → Cloudflare → Vercel/Container App → DB
|
|
78
|
+
|
|
79
|
+
2. **Identify Hidden Gaps** - Explicitly check if the change affects:
|
|
80
|
+
- **Cross-Region Handshakes**: Will this increase latency for users in Pakistan/India?
|
|
81
|
+
- **Forensic Continuity**: Does this change how Maya captures gaze or audio data?
|
|
82
|
+
- **Auth Persistence**: Will this interfere with WorkOS session tokens or M2M keys?
|
|
83
|
+
|
|
84
|
+
3. **Evidence-First**: Collect logs from \`talentlyt-dashboard\` before proposing a fix.
|
|
85
|
+
|
|
86
|
+
## Request Flow Tracing
|
|
87
|
+
|
|
88
|
+
\`\`\`
|
|
89
|
+
Client Browser
|
|
90
|
+
↓
|
|
91
|
+
Cloudflare (CDN/WAF)
|
|
92
|
+
↓
|
|
93
|
+
Azure Container Apps
|
|
94
|
+
├── talentlyt-dashboard (Next.js)
|
|
95
|
+
└── talentlyt-agent (Python/LiveKit)
|
|
96
|
+
↓
|
|
97
|
+
PostgreSQL Database
|
|
98
|
+
↓
|
|
99
|
+
Azure Blob Storage (recordings, evidence)
|
|
100
|
+
\`\`\`
|
|
101
|
+
|
|
102
|
+
## Evidence Collection
|
|
103
|
+
|
|
104
|
+
Before proposing any fix:
|
|
105
|
+
1. Get the actual error from logs (not assumed)
|
|
106
|
+
2. Identify the exact file and line number
|
|
107
|
+
3. Trace the data flow that led to the error
|
|
108
|
+
4. Verify the fix doesn't break other paths
|
|
109
|
+
`;
|
|
110
|
+
|
|
111
|
+
export const COLLABORATION_RULES = `
|
|
112
|
+
# Role & Collaboration
|
|
113
|
+
|
|
114
|
+
You are a Senior Staff Engineer working alongside a Principal Engineer (the user).
|
|
115
|
+
You do NOT work autonomously - you work collaboratively with approval at each step.
|
|
116
|
+
|
|
117
|
+
## 1. NO ASSUMPTIONS
|
|
118
|
+
- Never assume root cause without evidence from logs/code
|
|
119
|
+
- Never assume a fix works without verification
|
|
120
|
+
- Always trace the ACTUAL flow, not the expected flow
|
|
121
|
+
- When debugging, read the DEPLOYED code, not local code
|
|
122
|
+
|
|
123
|
+
## 2. APPROVAL REQUIRED
|
|
124
|
+
Before making ANY code change, you MUST:
|
|
125
|
+
1. Show the evidence (logs, code trace) proving the issue
|
|
126
|
+
2. Explain the root cause with proof
|
|
127
|
+
3. Propose the fix with rationale
|
|
128
|
+
4. Wait for explicit approval: "approved", "go ahead", "do it"
|
|
129
|
+
|
|
130
|
+
Exception: Only proceed without approval if user explicitly says "just do it" or "fix it"
|
|
131
|
+
|
|
132
|
+
## 3. NEVER LOSE TRACK
|
|
133
|
+
- Maintain TODO list for multi-step tasks
|
|
134
|
+
- Complete current task before starting new ones
|
|
135
|
+
- If interrupted, summarize current state before switching
|
|
136
|
+
- Reference previous findings, don't repeat investigations
|
|
137
|
+
|
|
138
|
+
## Communication
|
|
139
|
+
|
|
140
|
+
### When Reporting Issues
|
|
141
|
+
\`\`\`
|
|
142
|
+
**Evidence:** [actual log/error message]
|
|
143
|
+
**Location:** [file:line or endpoint]
|
|
144
|
+
**Root Cause:** [proven, not assumed]
|
|
145
|
+
**Privacy Impact:** [Does this affect biometric/PII data?]
|
|
146
|
+
**Fix:** [proposed solution]
|
|
147
|
+
\`\`\`
|
|
148
|
+
|
|
149
|
+
### When Asking for Approval
|
|
150
|
+
\`\`\`
|
|
151
|
+
I found: [evidence]
|
|
152
|
+
Root cause: [explanation]
|
|
153
|
+
Proposed fix: [code change summary]
|
|
154
|
+
|
|
155
|
+
Approve to proceed?
|
|
156
|
+
\`\`\`
|
|
157
|
+
|
|
158
|
+
### When Stuck
|
|
159
|
+
- Say "I need more information" not guess
|
|
160
|
+
- Ask specific questions
|
|
161
|
+
- Propose diagnostic steps
|
|
162
|
+
|
|
163
|
+
## Forbidden Actions
|
|
164
|
+
|
|
165
|
+
1. ❌ Making code changes without showing evidence first
|
|
166
|
+
2. ❌ Testing on localhost when asked to check production
|
|
167
|
+
3. ❌ Adding debug logs as a "fix"
|
|
168
|
+
4. ❌ Multiple deployment attempts hoping it works
|
|
169
|
+
5. ❌ Over-engineering simple solutions
|
|
170
|
+
6. ❌ Assuming secrets/env vars are available at init time
|
|
171
|
+
7. ❌ Ignoring user corrections
|
|
172
|
+
8. ❌ Losing context between messages
|
|
173
|
+
`;
|
package/src/commands/init.ts
CHANGED
|
@@ -3,6 +3,7 @@ import path from 'path';
|
|
|
3
3
|
import chalk from 'chalk';
|
|
4
4
|
import yaml from 'yaml';
|
|
5
5
|
import { DiscoveryService } from '@rigour-labs/core';
|
|
6
|
+
import { CODE_QUALITY_RULES, DEBUGGING_RULES, COLLABORATION_RULES } from './constants.js';
|
|
6
7
|
|
|
7
8
|
export interface InitOptions {
|
|
8
9
|
preset?: string;
|
|
@@ -107,12 +108,6 @@ Before claiming "Done" for any task, you MUST follow this loop:
|
|
|
107
108
|
3. **Refactor**: Apply **SOLID** and **DRY** principles to resolve the violations according to constraints.
|
|
108
109
|
4. **Repeat**: Continue until \`npx @rigour-labs/cli check\` returns **PASS**.
|
|
109
110
|
|
|
110
|
-
## 🧩 Engineering Standards
|
|
111
|
-
- **Single Responsibility**: Keep files small and focused (max 500 lines).
|
|
112
|
-
- **DRY (Don't Repeat Yourself)**: Extract common logic into utilities.
|
|
113
|
-
- **Done is Done**: No \`TODO\` or \`FIXME\` comments allowed in the final state.
|
|
114
|
-
- **Memory Preservation**: Always update docs/SPEC.md, docs/ARCH.md, docs/DECISIONS.md.
|
|
115
|
-
|
|
116
111
|
## 🛠️ Commands
|
|
117
112
|
\`\`\`bash
|
|
118
113
|
# Verify current state
|
|
@@ -121,6 +116,12 @@ npx @rigour-labs/cli check
|
|
|
121
116
|
# Self-healing agent loop
|
|
122
117
|
npx @rigour-labs/cli run -- <agent-command>
|
|
123
118
|
\`\`\`
|
|
119
|
+
|
|
120
|
+
${CODE_QUALITY_RULES}
|
|
121
|
+
|
|
122
|
+
${DEBUGGING_RULES}
|
|
123
|
+
|
|
124
|
+
${COLLABORATION_RULES}
|
|
124
125
|
`;
|
|
125
126
|
|
|
126
127
|
// 1. Create Universal Instructions
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest';
|
|
2
|
+
import { initCommand } from './commands/init.js';
|
|
3
|
+
import fs from 'fs-extra';
|
|
4
|
+
import path from 'path';
|
|
5
|
+
|
|
6
|
+
describe('Init Command Rules Verification', () => {
|
|
7
|
+
const testDir = path.join(process.cwd(), 'temp-init-rules-test');
|
|
8
|
+
|
|
9
|
+
beforeEach(async () => {
|
|
10
|
+
await fs.ensureDir(testDir);
|
|
11
|
+
});
|
|
12
|
+
|
|
13
|
+
afterEach(async () => {
|
|
14
|
+
await fs.remove(testDir);
|
|
15
|
+
});
|
|
16
|
+
|
|
17
|
+
it('should create universal instructions and cursor rules on init', async () => {
|
|
18
|
+
// Run init in test directory
|
|
19
|
+
await initCommand(testDir);
|
|
20
|
+
|
|
21
|
+
const instructionsPath = path.join(testDir, 'docs', 'AGENT_INSTRUCTIONS.md');
|
|
22
|
+
const mdcPath = path.join(testDir, '.cursor', 'rules', 'rigour.mdc');
|
|
23
|
+
|
|
24
|
+
expect(await fs.pathExists(instructionsPath)).toBe(true);
|
|
25
|
+
expect(await fs.pathExists(mdcPath)).toBe(true);
|
|
26
|
+
|
|
27
|
+
const instructionsContent = await fs.readFile(instructionsPath, 'utf-8');
|
|
28
|
+
const mdcContent = await fs.readFile(mdcPath, 'utf-8');
|
|
29
|
+
|
|
30
|
+
// Check for key sections in universal instructions
|
|
31
|
+
expect(instructionsContent).toContain('# 🛡️ Rigour: Engineering Excellence Protocol');
|
|
32
|
+
expect(instructionsContent).toContain('# Code Quality Standards');
|
|
33
|
+
expect(instructionsContent).toContain('# Investigation & Debugging Protocol');
|
|
34
|
+
expect(instructionsContent).toContain('# Role & Collaboration');
|
|
35
|
+
|
|
36
|
+
// Check that MDC includes frontmatter and same rules
|
|
37
|
+
expect(mdcContent).toContain('---');
|
|
38
|
+
expect(mdcContent).toContain('description: Enforcement of Rigour quality gates and best practices.');
|
|
39
|
+
expect(mdcContent).toContain('# Code Quality Standards');
|
|
40
|
+
});
|
|
41
|
+
});
|