majlis 0.4.1 → 0.4.2

package/dist/cli.js

@@ -522,24 +522,35 @@ Before building:
 3. Check docs/classification/ for problem taxonomy
 4. Check docs/experiments/ for prior work
 
-## Scope Constraint (CRITICAL)
+Read as much code as you need to understand the problem. Reading is free \u2014 spend
+as many turns as necessary on Read, Grep, and Glob to build full context before
+you touch anything.
+
+## The Rule: ONE Change, Then Document
+
+You make ONE code change per cycle. Not two, not "one more quick fix." ONE.
+
+The sequence:
+1. **Read and understand** \u2014 read synthesis, dead-ends, source code. Take your time.
+2. **Write the experiment doc FIRST** \u2014 before coding, fill in the Approach section
+   with what you plan to do and why. This ensures there is always a record.
+3. **Implement ONE focused change** \u2014 a single coherent edit to the codebase.
+4. **Run the benchmark ONCE** \u2014 observe the result.
+5. **Update the experiment doc** \u2014 fill in Results and Metrics with what happened.
+6. **Output the majlis-json block** \u2014 your structured decisions.
+7. **STOP.**
 
-You get ONE attempt per cycle. Your job is:
-1. Read and diagnose \u2014 understand the problem thoroughly
-2. Form ONE hypothesis about what to fix
-3. Implement ONE focused change (not a multi-step debug session)
-4. Run the benchmark ONCE to see the result
-5. Update the experiment doc in docs/experiments/ \u2014 fill in Approach, Results, and Metrics sections. This is NOT optional.
-6. Output the structured majlis-json block with your decisions
-7. STOP
+If your change doesn't work, document what happened and STOP. Do NOT try to fix it.
+Do NOT iterate. Do NOT "try one more thing." The adversary, critic, and verifier
+exist to diagnose what went wrong. The cycle comes back to you with their insights.
 
-Do NOT iterate. Do NOT try multiple approaches. Do NOT debug your own fix.
-If your change doesn't work, document why and let the cycle continue \u2014
-the adversary, critic, and verifier will help diagnose what went wrong.
-The cycle will come back to you with their insights.
+If you find yourself wanting to debug your own fix, that's the signal to stop
+and write up what you learned.
 
-If you find yourself wanting to "try one more thing," that's the signal to stop
-and write up what you learned. The other agents exist precisely for this reason.
+## Off-limits (DO NOT modify)
+- \`fixtures/\` \u2014 test data, ground truth, STL files. Read-only.
+- \`scripts/benchmark.py\` \u2014 the measurement tool. Never change how you're measured.
+- \`.majlis/\` \u2014 framework config. Not your concern.
 
 ## During building:
 - Tag EVERY decision: proof / test / strong-consensus / consensus / analogy / judgment
@@ -2460,7 +2471,7 @@ var init_spawn = __esm({
     init_parse();
     init_connection();
     ROLE_MAX_TURNS = {
-      builder: 15,
+      builder: 50,
       critic: 12,
       adversary: 12,
       verifier: 15,
@@ -3286,7 +3297,8 @@ ${deadEnds.map((d) => `- ${d.approach}: ${d.why_failed} [constraint: ${d.structu
 3. If NO \u2014 propose the SINGLE most promising next experiment hypothesis.
    - It must NOT repeat a dead-ended approach (check the dead-end registry!)
    - It should attack the weakest point revealed by synthesis/fragility
-   - It must be specific and actionable \u2014 name the exact code/function/mechanism to change
+   - It must be specific and actionable \u2014 name the function or mechanism to change
+   - Do NOT reference specific line numbers \u2014 they shift between experiments
    - The hypothesis should be a single sentence describing what to do, e.g.:
      "Activate addSeamEdges() in the runEdgeFirst pipeline for full-revolution cylinder faces"
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "majlis",
-  "version": "0.4.1",
+  "version": "0.4.2",
   "description": "Multi-agent workflow CLI for structured doubt, independent verification, and compressed knowledge",
   "bin": {
     "majlis": "./dist/cli.js"