@rigour-labs/cli 2.5.1 → 2.6.0

package/dist/commands/constants.d.ts

@@ -1,3 +1,3 @@
 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";
 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";
-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";
+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## \u26A0\uFE0F RIGOUR.YML IS SACRED\n\nThe `rigour.yml` file represents **team-agreed quality standards**. You are FORBIDDEN from:\n\n1. \u274C Increasing thresholds to pass checks (e.g., raising `complexity: 100`)\n2. \u274C Adding patterns to `ignore:` to skip problematic files\n3. \u274C Removing items from `required_files`\n4. \u274C Disabling gates to avoid failures\n\n**Your job is to FIX THE CODE to meet the standards, NOT weaken the standards to pass the check.**\n\nIf thresholds genuinely need adjustment, escalate to the team lead with justification.\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\n9. \u274C Modifying rigour.yml to pass quality checks\n";

package/dist/commands/constants.js

@@ -161,6 +161,19 @@ Approve to proceed?
 - Ask specific questions
 - Propose diagnostic steps
 
+## ⚠️ RIGOUR.YML IS SACRED
+
+The \`rigour.yml\` file represents **team-agreed quality standards**. You are FORBIDDEN from:
+
+1. ❌ Increasing thresholds to pass checks (e.g., raising \`complexity: 100\`)
+2. ❌ Adding patterns to \`ignore:\` to skip problematic files
+3. ❌ Removing items from \`required_files\`
+4. ❌ Disabling gates to avoid failures
+
+**Your job is to FIX THE CODE to meet the standards, NOT weaken the standards to pass the check.**
+
+If thresholds genuinely need adjustment, escalate to the team lead with justification.
+
 ## Forbidden Actions
 
 1. ❌ Making code changes without showing evidence first
@@ -171,4 +184,5 @@ Approve to proceed?
 6. ❌ Assuming secrets/env vars are available at init time
 7. ❌ Ignoring user corrections
 8. ❌ Losing context between messages
+9. ❌ Modifying rigour.yml to pass quality checks
 `;

package/dist/commands/init.js

@@ -74,7 +74,13 @@ async function initCommand(cwd, options = {}) {
         console.log(chalk_1.default.cyan(`   Paradigm: `) + chalk_1.default.bold(recommendedConfig.paradigm.toUpperCase()));
     }
     console.log('');
-    await fs_extra_1.default.writeFile(configPath, yaml_1.default.stringify(recommendedConfig));
+    const yamlHeader = `# ⚠️ TEAM STANDARD - DO NOT MODIFY WITHOUT TEAM APPROVAL
+# AI Assistants: Adjust YOUR code to meet these standards, not the other way around.
+# Modifying thresholds or adding ignores to pass checks defeats the purpose of Rigour.
+# See: docs/AGENT_INSTRUCTIONS.md for the correct workflow.
+
+`;
+    await fs_extra_1.default.writeFile(configPath, yamlHeader + yaml_1.default.stringify(recommendedConfig));
     console.log(chalk_1.default.green('✔ Created rigour.yml'));
     // Create required directories and files
     const requireddocs = recommendedConfig.gates.required_files || [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rigour-labs/cli",
-  "version": "2.5.1",
+  "version": "2.6.0",
   "bin": {
     "rigour": "dist/cli.js"
   },
@@ -21,7 +21,7 @@
     "globby": "^14.0.1",
     "inquirer": "9.2.16",
     "yaml": "^2.8.2",
-    "@rigour-labs/core": "2.5.1"
+    "@rigour-labs/core": "2.6.0"
   },
   "devDependencies": {
     "@types/fs-extra": "^11.0.4",

package/src/commands/constants.ts

@@ -160,6 +160,19 @@ Approve to proceed?
 - Ask specific questions
 - Propose diagnostic steps
 
+## ⚠️ RIGOUR.YML IS SACRED
+
+The \`rigour.yml\` file represents **team-agreed quality standards**. You are FORBIDDEN from:
+
+1. ❌ Increasing thresholds to pass checks (e.g., raising \`complexity: 100\`)
+2. ❌ Adding patterns to \`ignore:\` to skip problematic files
+3. ❌ Removing items from \`required_files\`
+4. ❌ Disabling gates to avoid failures
+
+**Your job is to FIX THE CODE to meet the standards, NOT weaken the standards to pass the check.**
+
+If thresholds genuinely need adjustment, escalate to the team lead with justification.
+
 ## Forbidden Actions
 
 1. ❌ Making code changes without showing evidence first
@@ -170,4 +183,5 @@ Approve to proceed?
 6. ❌ Assuming secrets/env vars are available at init time
 7. ❌ Ignoring user corrections
 8. ❌ Losing context between messages
+9. ❌ Modifying rigour.yml to pass quality checks
 `;

package/src/commands/init.ts

@@ -78,7 +78,13 @@ export async function initCommand(cwd: string, options: InitOptions = {}) {
     }
     console.log('');
 
-    await fs.writeFile(configPath, yaml.stringify(recommendedConfig));
+    const yamlHeader = `# ⚠️ TEAM STANDARD - DO NOT MODIFY WITHOUT TEAM APPROVAL
+# AI Assistants: Adjust YOUR code to meet these standards, not the other way around.
+# Modifying thresholds or adding ignores to pass checks defeats the purpose of Rigour.
+# See: docs/AGENT_INSTRUCTIONS.md for the correct workflow.
+
+`;
+    await fs.writeFile(configPath, yamlHeader + yaml.stringify(recommendedConfig));
     console.log(chalk.green('✔ Created rigour.yml'));
 
     // Create required directories and files