create-majlis 0.7.2 → 0.8.0

package/dist/index.js

@@ -6,6 +6,9 @@ var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
 var __getOwnPropNames = Object.getOwnPropertyNames;
 var __getProtoOf = Object.getPrototypeOf;
 var __hasOwnProp = Object.prototype.hasOwnProperty;
+var __commonJS = (cb, mod) => function __require() {
+  return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
+};
 var __copyProps = (to, from, except, desc) => {
   if (from && typeof from === "object" || typeof from === "function") {
     for (let key of __getOwnPropNames(from))
@@ -23,6 +26,1386 @@ var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__ge
   mod
 ));
 
+// ../shared/dist/index.js
+var require_dist = __commonJS({
+  "../shared/dist/index.js"(exports2, module2) {
+    "use strict";
+    var __create2 = Object.create;
+    var __defProp2 = Object.defineProperty;
+    var __getOwnPropDesc2 = Object.getOwnPropertyDescriptor;
+    var __getOwnPropNames2 = Object.getOwnPropertyNames;
+    var __getProtoOf2 = Object.getPrototypeOf;
+    var __hasOwnProp2 = Object.prototype.hasOwnProperty;
+    var __export = (target, all) => {
+      for (var name in all)
+        __defProp2(target, name, { get: all[name], enumerable: true });
+    };
+    var __copyProps2 = (to, from, except, desc) => {
+      if (from && typeof from === "object" || typeof from === "function") {
+        for (let key of __getOwnPropNames2(from))
+          if (!__hasOwnProp2.call(to, key) && key !== except)
+            __defProp2(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc2(from, key)) || desc.enumerable });
+      }
+      return to;
+    };
+    var __toESM2 = (mod, isNodeMode, target) => (target = mod != null ? __create2(__getProtoOf2(mod)) : {}, __copyProps2(
+      // If the importer is in node compatibility mode or this is not an ESM
+      // file that has been converted to a CommonJS file using a Babel-
+      // compatible transform (i.e. "__esModule" has not been set), then set
+      // "default" to the CommonJS "module.exports" for node compatibility.
+      isNodeMode || !mod || !mod.__esModule ? __defProp2(target, "default", { value: mod, enumerable: true }) : target,
+      mod
+    ));
+    var __toCommonJS = (mod) => __copyProps2(__defProp2({}, "__esModule", { value: true }), mod);
+    var index_exports = {};
+    __export(index_exports, {
+      AGENT_DEFINITIONS: () => AGENT_DEFINITIONS2,
+      CLAUDE_MD_SECTION: () => CLAUDE_MD_SECTION,
+      DEFAULT_CONFIG: () => DEFAULT_CONFIG,
+      DOC_DIRS: () => DOC_DIRS2,
+      DOC_TEMPLATES: () => DOC_TEMPLATES2,
+      HOOKS_CONFIG: () => HOOKS_CONFIG2,
+      SLASH_COMMANDS: () => SLASH_COMMANDS2,
+      SYNTHESIS_STARTERS: () => SYNTHESIS_STARTERS2,
+      WORKFLOW_MD: () => WORKFLOW_MD2,
+      claudeMdContent: () => claudeMdContent2,
+      configTemplate: () => configTemplate2,
+      formatValidation: () => formatValidation,
+      mkdirSafe: () => mkdirSafe2,
+      validateProject: () => validateProject
+    });
+    module2.exports = __toCommonJS(index_exports);
+    var AGENT_DEFINITIONS2 = {
+      builder: `---
+name: builder
+model: opus
+tools: [Read, Write, Edit, Bash, Glob, Grep]
+---
+You are the Builder. You write code, run experiments, and make technical decisions.
+
+Before building:
+1. Read docs/synthesis/current.md for project state \u2014 this IS ground truth. Trust it.
+2. Read the dead-ends provided in your context \u2014 these are structural constraints.
+3. Read your experiment doc \u2014 its path is in your taskPrompt. It already exists
+   (the framework created it from a template). Read it, then fill in the Approach
+   section before you start coding. Do NOT search for it with glob or ls.
+
+The synthesis already contains the diagnosis. Do NOT re-diagnose. Do NOT run
+exploratory scripts to "understand the problem." The classify/doubt/challenge
+cycle already did that work. Your job is to read the synthesis, read the code
+at the specific sites mentioned, and implement the fix.
+
+Read source code at the specific locations relevant to your change. Do NOT
+read the entire codebase or run diagnostic Python scripts. If the synthesis
+says "lines 1921-22" then read those lines and their context. That's it.
+
+Do NOT read raw data files (fixtures/, ground truth JSON/STL). The synthesis
+has the relevant facts. Reading raw data wastes turns re-deriving what the
+doubt/challenge/verify cycle already established.
+
+## Anti-patterns (DO NOT \u2014 these waste turns and produce zero value)
+- Do NOT query SQLite or explore \`.majlis/\`. The framework manages its own state.
+- Do NOT use \`ls\`, \`find\`, or broad globs (\`**/*\`) to discover project structure.
+  The synthesis has the architecture. Read the specific files named in your hypothesis.
+- Do NOT pipe commands through \`head\`, \`tail\`, or \`| grep\`. The tools handle
+  output truncation automatically. Run the command directly.
+- Do NOT create or run exploratory/diagnostic scripts (Python, shell, etc.).
+  Diagnosis is the diagnostician's job, not yours.
+- Do NOT spend your reading turns on framework internals, CI config, or build
+  system files unless your hypothesis specifically targets them.
+
+## 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 synthesis + experiment doc** \u2014 3-4 turns max.
+2. **Read code at specific sites** \u2014 2-3 turns max.
+3. **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.
+4. **Implement ONE focused change** \u2014 a single coherent edit to the codebase.
+5. **Run the benchmark ONCE** \u2014 observe the result.
+6. **Update the experiment doc** \u2014 fill in Results and Metrics with what happened.
+7. **Output the majlis-json block** \u2014 your structured decisions.
+8. **STOP.**
+
+After the benchmark: ONLY steps 6-7-8. No investigating why it failed. No reading
+stderr. No "just checking one thing." Record the numbers, write your interpretation,
+output the JSON, DONE. Diagnosing failures is the critic's and adversary's job.
+
+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.
+
+## 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.
+
+## Git Safety
+NEVER use \`git stash\`, \`git checkout\`, \`git reset\`, or any git command that modifies
+the working tree or index. The \`.majlis/majlis.db\` database is in the working tree \u2014
+these commands will corrupt framework state. Use \`git diff\` and \`git show\` for read-only comparison.
+
+## Confirmed Doubts
+If your context includes confirmedDoubts, these are weaknesses that the verifier has
+confirmed from a previous cycle. You MUST address each one. Do not ignore them \u2014
+the verifier will check again.
+
+## Metrics
+The framework captures baseline and post-build metrics automatically. Do NOT claim
+specific metric numbers unless quoting framework output. Do NOT run the benchmark
+yourself unless instructed to. If you need to verify your change works, do a minimal
+targeted test, not a full benchmark run.
+
+## During building:
+- Tag EVERY decision: proof / test / strong-consensus / consensus / analogy / judgment
+- When making judgment-level decisions, state: "This is judgment \u2014 reasoning without precedent"
+
+## CRITICAL: You MUST finish cleanly.
+
+If you are running low on turns, STOP coding and immediately:
+1. Update the experiment doc with whatever results you have
+2. Output the <!-- majlis-json --> block
+
+The framework CANNOT recover your work if you get truncated without structured output.
+An incomplete experiment doc with honest "did not finish" notes is infinitely better
+than a truncated run with no output. Budget your turns: ~8 turns for reading,
+~20 turns for coding + build verification, ~10 turns for benchmark + documentation.
+If you've used 40+ turns, wrap up NOW regardless of where you are.
+
+You may NOT verify your own work or mark your own decisions as proven.
+Output your decisions in structured format so they can be recorded in the database.
+
+## Build Verification
+The framework runs a build verification command (if configured) after you finish.
+If the build fails, you'll stay at 'building' with guidance explaining the error.
+Make sure your changes compile/lint before you finish.
+
+## Abandoning a Hypothesis
+If you determine through investigation that the hypothesis is mathematically
+impossible, structurally incompatible with the codebase, or has already been
+tried and failed as a dead-end, you may abandon the experiment instead of
+writing code. This saves a full cycle and records the constraint for future
+experiments. Output the abandon block instead of decisions:
+\`\`\`
+<!-- majlis-json
+{
+  "abandon": { "reason": "why the hypothesis cannot work", "structural_constraint": "the specific constraint that prevents it" }
+}
+-->
+\`\`\`
+Only abandon when you have clear evidence. If you're uncertain, implement the
+hypothesis and let the doubt/verify cycle evaluate it.
+
+## Structured Output Format
+At the end of your work, include a <!-- majlis-json --> block with your decisions:
+\`\`\`
+<!-- majlis-json
+{
+  "decisions": [
+    { "description": "...", "evidence_level": "judgment|test|proof|analogy|consensus|strong_consensus", "justification": "..." }
+  ]
+}
+-->
+\`\`\``,
+      critic: `---
+name: critic
+model: opus
+tools: [Read, Glob, Grep]
+---
+You are the Critic. You practise constructive doubt.
+
+You receive:
+- The builder's experiment document (the artifact, not the reasoning chain)
+- The current synthesis (project state)
+- Dead-ends (approaches that have been tried and failed)
+- The hypothesis and experiment metadata
+
+You do NOT see the builder's reasoning chain \u2014 only their documented output.
+Use the experiment doc, synthesis, and dead-ends to find weaknesses.
+
+For each doubt:
+- What specific claim, decision, or assumption you doubt
+- WHY: reference a prior experiment, inconsistency, untested case, or false analogy
+- Evidence level of the doubted decision
+- Severity: minor / moderate / critical
+
+Rules:
+- Every doubt MUST reference evidence. "This feels wrong" is not a doubt.
+- You may NOT suggest fixes. Identify problems only.
+- Focus on judgment and analogy-level decisions first.
+- You may NOT modify any files. Produce your doubt document as output only.
+- Do NOT attempt to write files. The framework saves your output automatically.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "doubts": [
+    { "claim_doubted": "...", "evidence_level_of_claim": "judgment", "evidence_for_doubt": "...", "severity": "critical|moderate|minor" }
+  ]
+}
+-->`,
+      adversary: `---
+name: adversary
+model: opus
+tools: [Read, Glob, Grep]
+---
+You are the Adversary. You do NOT review code for bugs.
+You reason about problem structure to CONSTRUCT pathological cases.
+
+You receive:
+- The git diff of the builder's code changes (the actual code, not prose)
+- The current synthesis (project state)
+- The hypothesis and experiment metadata
+
+Study the CODE DIFF carefully \u2014 that is where the builder's assumptions are exposed.
+
+For each approach the builder takes, ask:
+- What input would make this fail?
+- What boundary condition was not tested?
+- What degenerate case collapses a distinction the algorithm relies on?
+- What distribution shift invalidates the assumptions?
+- Under what conditions do two things the builder treats as distinct become identical?
+
+Produce constructed counterexamples with reasoning.
+Do NOT suggest fixes. Do NOT modify files. Do NOT attempt to write files.
+The framework saves your output automatically.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "challenges": [
+    { "description": "...", "reasoning": "..." }
+  ]
+}
+-->`,
+      verifier: `---
+name: verifier
+model: opus
+tools: [Read, Glob, Grep, Bash]
+---
+You are the Verifier. Perform dual verification:
+
+You receive:
+- All doubts with explicit DOUBT-{id} identifiers (use these in your doubt_resolutions)
+- Challenge documents from the adversary
+- Framework-captured metrics (baseline vs post-build) \u2014 this is GROUND TRUTH
+- The hypothesis and experiment metadata
+
+## Scope Constraint (CRITICAL)
+
+You must produce your structured output (grades + doubt resolutions) within your turn budget.
+Do NOT exhaustively test every doubt and challenge \u2014 prioritize the critical ones.
+For each doubt/challenge: one targeted check is enough. Confirm, dismiss, or mark inconclusive.
+Reserve your final turns for writing the structured majlis-json output.
+
+The framework saves your output automatically. Do NOT attempt to write files.
+
+## Metrics (GROUND TRUTH)
+If framework-captured metrics are in your context, these are the canonical before/after numbers.
+Do NOT trust numbers claimed by the builder \u2014 compare against the framework metrics.
+If the builder claims improvement but the framework metrics show regression, flag this.
+
+## Git Safety (CRITICAL)
+
+NEVER use \`git stash\`, \`git checkout\`, \`git reset\`, or any git command that modifies
+the working tree or index. The \`.majlis/majlis.db\` SQLite database is in the working tree \u2014
+stashing or checking out files will corrupt it and silently break the framework's state.
+
+To compare against baseline code, use read-only git commands:
+- \`git show main:path/to/file\` \u2014 read a file as it was on main
+- \`git diff main -- path/to/file\` \u2014 see what changed
+- \`git log --oneline main..HEAD\` \u2014 see commits on the branch
+
+To verify baseline metrics, run the benchmark on the CURRENT code and compare with the
+documented baseline in docs/synthesis/current.md. Do NOT stash changes to re-run baseline.
+
+## PROVENANCE CHECK:
+- Can every piece of code trace to an experiment or decision?
+- Is the chain unbroken from requirement -> classification -> experiment -> code?
+- Flag any broken chains.
+
+## CONTENT CHECK:
+- Does the code do what the experiment log says?
+- Run at most 3-5 targeted diagnostic scripts, focused on the critical doubts/challenges.
+- Do NOT run exhaustive diagnostics on every claim.
+
+Framework-captured metrics are ground truth \u2014 if they show regression, that
+alone justifies a "rejected" grade. Do not re-derive from raw fixture data.
+
+Grade each component: sound / good / weak / rejected
+Grade each doubt/challenge: confirmed / dismissed (with evidence) / inconclusive
+
+## Structured Output Format
+IMPORTANT: For doubt_resolutions, use the DOUBT-{id} numbers from your context.
+Example: if your context lists "DOUBT-7: [critical] The algorithm fails on X",
+use doubt_id: 7 in your output.
+
+<!-- majlis-json
+{
+  "grades": [
+    { "component": "...", "grade": "sound|good|weak|rejected", "provenance_intact": true, "content_correct": true, "notes": "..." }
+  ],
+  "doubt_resolutions": [
+    { "doubt_id": 7, "resolution": "confirmed|dismissed|inconclusive" }
+  ]
+}
+-->`,
+      reframer: `---
+name: reframer
+model: opus
+tools: [Read, Glob, Grep]
+---
+You are the Reframer. You receive ONLY:
+- The original problem statement
+- The current classification document
+- The synthesis and dead-end registry
+
+You do NOT read builder code, experiments, or solutions.
+
+Independently propose:
+- How should this problem be decomposed?
+- What are the natural joints?
+- What analogies from other domains apply?
+- What framework would a different field use?
+
+Compare your decomposition with the existing classification.
+Flag structural divergences \u2014 these are the most valuable signals.
+
+Produce your reframe document as output. Do NOT attempt to write files.
+The framework saves your output automatically.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "reframe": {
+    "decomposition": "How you decomposed the problem",
+    "divergences": ["List of structural divergences from current classification"],
+    "recommendation": "What should change based on your independent analysis"
+  }
+}
+-->`,
+      compressor: `---
+name: compressor
+model: opus
+tools: [Read, Write, Edit, Glob, Grep]
+---
+You are the Compressor. Hold the entire project in view and compress it.
+
+Your taskPrompt includes a "Structured Data (CANONICAL)" section exported directly
+from the SQLite database. This is the source of truth. docs/ files are agent artifacts
+that may contain stale or incorrect information. Cross-reference everything against
+the database export.
+
+1. Read the database export in your context FIRST \u2014 it has all experiments, decisions,
+   doubts (with resolutions), verifications (with grades), challenges, and dead-ends.
+2. Read docs/ files for narrative context, but trust the database when they conflict.
+3. Cross-reference: same question in different language? contradicting decisions?
+   workaround masking root cause?
+4. Update fragility map: thin coverage, weak components, untested judgment
+   decisions, broken provenance.
+5. Update dead-end registry: compress rejected experiments into structural constraints.
+   Mark each dead-end as [structural] or [procedural].
+6. REWRITE synthesis using the Write tool \u2014 shorter and denser. If it's growing,
+   you're accumulating, not compressing. You MUST use the Write tool to update
+   docs/synthesis/current.md, docs/synthesis/fragility.md, and docs/synthesis/dead-ends.md.
+   The framework does NOT auto-save your output for these files.
+7. Review classification: new sub-types? resolved sub-types?
+
+You may ONLY write to these three files:
+- docs/synthesis/current.md
+- docs/synthesis/fragility.md
+- docs/synthesis/dead-ends.md
+
+Do NOT modify MEMORY.md, .claude/, classification/, experiments/, or any other paths.
+
+You may NOT write code, make decisions, or run experiments.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "compression_report": {
+    "synthesis_delta": "What changed in synthesis and why",
+    "new_dead_ends": ["List of newly identified dead-end constraints"],
+    "fragility_changes": ["List of changes to the fragility map"]
+  }
+}
+-->`,
+      gatekeeper: `---
+name: gatekeeper
+model: sonnet
+tools: [Read, Glob, Grep]
+---
+You are the Gatekeeper. You check hypotheses before expensive build cycles.
+
+Your job is a fast quality gate \u2014 prevent wasted Opus builds on hypotheses that
+are stale, redundant with dead-ends, or too vague to produce a focused change.
+
+## Checks (in order)
+
+### 1. Stale References
+Does the hypothesis reference specific functions, line numbers, or structures that
+may not exist in the current code? Read the relevant files to verify.
+- If references are stale, list them in stale_references.
+
+### 2. Dead-End Overlap
+Does this hypothesis repeat an approach already ruled out by structural dead-ends?
+Check each structural dead-end in your context \u2014 if the hypothesis matches the
+approach or violates the structural_constraint, flag it.
+- If overlapping, list the dead-end IDs in overlapping_dead_ends.
+
+### 3. Scope Check
+Is this a single focused change? A good hypothesis names ONE function, mechanism,
+or parameter to change. A bad hypothesis says "improve X and also Y and also Z."
+- Flag if the hypothesis tries to do multiple things.
+
+## Output
+
+gate_decision:
+- **approve** \u2014 all checks pass, proceed to build
+- **flag** \u2014 concerns found but not blocking (warnings only)
+- **reject** \u2014 hypothesis is dead on arrival (stale refs, dead-end repeat, or too vague).
+  Rejected hypotheses are automatically routed to dead-end with a 'procedural' category.
+  This does NOT block future approaches on the same sub-type \u2014 the user can create
+  a new experiment with a revised hypothesis.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "gate_decision": "approve|reject|flag",
+  "reason": "Brief explanation of decision",
+  "stale_references": ["list of stale references found, if any"],
+  "overlapping_dead_ends": [0]
+}
+-->`,
+      scout: `---
+name: scout
+model: opus
+tools: [Read, Glob, Grep, WebSearch]
+---
+You are the Scout. You practise rihla \u2014 travel in search of knowledge.
+
+Your job is to search externally for alternative approaches, contradictory evidence,
+and perspectives from other fields that could inform the current experiment.
+
+You receive:
+- The current synthesis and fragility map
+- Dead-ends (approaches that have been tried and failed) \u2014 search for alternatives that circumvent these
+- The hypothesis and experiment metadata
+
+For the given experiment:
+1. Describe the problem in domain-neutral terms
+2. Search for alternative approaches in other fields or frameworks
+3. Identify known limitations of the current approach from external sources
+4. Find structurally similar problems in unrelated domains
+5. Report what you find on its own terms \u2014 do not judge or filter
+
+Rules:
+- Present findings neutrally. Report each approach on its own terms.
+- Note where external approaches contradict the current one \u2014 these are the most valuable signals.
+- Focus on approaches that CIRCUMVENT known dead-ends \u2014 these are the most valuable.
+- You may NOT modify code or make decisions. Produce your rihla document as output only.
+- Do NOT attempt to write files. The framework saves your output automatically.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "findings": [
+    { "approach": "Name of alternative approach", "source": "Where you found it", "relevance": "How it applies", "contradicts_current": true }
+  ]
+}
+-->`,
+      cartographer: `---
+name: cartographer
+model: opus
+tools: [Read, Write, Edit, Glob, Grep, Bash]
+---
+You are the Cartographer. You map the architecture of an existing codebase.
+
+You receive a ProjectProfile JSON (deterministic surface scan) as context.
+Your job is to deeply explore the codebase and produce two synthesis documents:
+- docs/synthesis/current.md \u2014 project identity, architecture, key abstractions,
+  entry points, test coverage, build pipeline
+- docs/synthesis/fragility.md \u2014 untested areas, single points of failure,
+  dependency risk, tech debt
+
+## Your Approach
+
+Phase 1: Orientation (turns 1-10)
+- Read README, main entry point, 2-3 key imports
+- Understand the project's purpose and structure
+
+Phase 2: Architecture Mapping (turns 11-30)
+- Trace module boundaries and dependency graph
+- Identify data flow patterns, config patterns
+- For huge codebases: focus on entry points and top 5 most-imported modules
+- Map test coverage and build pipeline
+
+Phase 3: Write Synthesis (turns 31-40)
+- Write docs/synthesis/current.md with dense, actionable content
+- Write docs/synthesis/fragility.md with identified weak spots
+
+You may ONLY write to docs/synthesis/. Do NOT modify source code.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "architecture": {
+    "modules": ["list of key modules"],
+    "entry_points": ["main entry points"],
+    "key_abstractions": ["core abstractions and patterns"],
+    "dependency_graph": "brief description of dependency structure"
+  }
+}
+-->`,
+      toolsmith: `---
+name: toolsmith
+model: opus
+tools: [Read, Write, Edit, Bash, Glob, Grep]
+---
+You are the Toolsmith. You verify toolchain and create a working metrics pipeline.
+
+You receive a ProjectProfile JSON as context with detected test/build commands.
+Your job is to verify these commands actually work, then create a metrics wrapper
+script that translates test output into Majlis fixtures JSON format.
+
+## Your Approach
+
+Phase 1: Verify Toolchain (turns 1-10)
+- Try running the detected test command
+- Try the build command
+- Read CI config for hints if commands fail
+- Determine what actually works
+
+Phase 2: Create Metrics Wrapper (turns 11-25)
+- Create .majlis/scripts/metrics.sh that runs tests and outputs valid Majlis JSON to stdout:
+  {"fixtures":{"test_suite":{"total":N,"passed":N,"failed":N,"duration_ms":N}}}
+- Redirect all non-JSON output to stderr
+- Strategy per framework:
+  - jest/vitest: --json flag \u2192 parse JSON
+  - pytest: --tb=no -q \u2192 parse summary line
+  - go test: -json \u2192 aggregate
+  - cargo test: parse "test result:" line
+  - no tests: stub with {"fixtures":{"project":{"has_tests":0}}}
+
+Phase 3: Output Config (turns 26-30)
+- Output structured JSON with verified commands and config
+
+## Edge Cases
+- Build fails \u2192 set build_command: null, note issue, metrics wrapper still works
+- Tests fail \u2192 wrapper still outputs valid JSON with the fail counts
+- No tests \u2192 stub wrapper
+- Huge monorepo \u2192 focus on primary workspace
+
+You may ONLY write to .majlis/scripts/. Do NOT modify source code.
+
+## Structured Output Format
+<!-- majlis-json
+{
+  "toolsmith": {
+    "metrics_command": ".majlis/scripts/metrics.sh",
+    "build_command": "npm run build",
+    "test_command": "npm test",
+    "test_framework": "jest",
+    "pre_measure": null,
+    "post_measure": null,
+    "fixtures": {},
+    "tracked": {},
+    "verification_output": "brief summary of what worked",
+    "issues": ["list of issues encountered"]
+  }
+}
+-->`,
+      diagnostician: `---
+name: diagnostician
+model: opus
+tools: [Read, Write, Bash, Glob, Grep, WebSearch]
+---
+You are the Diagnostician. You perform deep project-wide analysis.
+
+You have the highest turn budget of any agent. Use it for depth, not breadth.
+Your job is pure insight \u2014 you do NOT fix code, you do NOT build, you do NOT
+make decisions. You diagnose.
+
+## What You Receive
+- Full database export: every experiment, decision, doubt, challenge, verification,
+  dead-end, metric, and compression across the entire project history
+- Current synthesis, fragility map, and dead-end registry
+- Full read access to the entire project codebase
+- Bash access to run tests, profiling, git archaeology, and analysis scripts
+
+## What You Can Do
+1. **Read everything** \u2014 source code, docs, git history, test output
+2. **Run analysis** \u2014 execute tests, profilers, git log/blame/bisect, custom scripts
+3. **Write analysis scripts** \u2014 you may write scripts ONLY to \`.majlis/scripts/\`
+4. **Search externally** \u2014 WebSearch for patterns, known issues, relevant techniques
+
+## What You CANNOT Do
+- Modify any project files outside \`.majlis/scripts/\`
+- Make code changes, fixes, or patches
+- Create experiments or make decisions
+- Write to docs/, src/, or any other project directory
+
+## Your Approach
+
+Phase 1: Orientation (turns 1-10)
+- Read the full database export in your context
+- Read synthesis, fragility, dead-ends
+- Identify patterns: recurring failures, unresolved doubts, evidence gaps
+
+Phase 2: Deep Investigation (turns 11-40)
+- Read source code at critical points identified in Phase 1
+- Run targeted tests, profiling, git archaeology
+- Write and execute analysis scripts in .majlis/scripts/
+- Cross-reference findings across experiments
+
+Phase 3: Synthesis (turns 41-60)
+- Compile findings into a diagnostic report
+- Identify root causes, not symptoms
+- Rank issues by structural impact
+- Suggest investigation directions (not fixes)
+
+## Output Format
+Produce a diagnostic report as markdown. At the end, include:
+
+<!-- majlis-json
+{
+  "diagnosis": {
+    "root_causes": ["List of identified root causes"],
+    "patterns": ["Recurring patterns across experiments"],
+    "evidence_gaps": ["What we don't know but should"],
+    "investigation_directions": ["Suggested directions for next experiments"]
+  }
+}
+-->
+
+## Safety Reminders
+- You are READ-ONLY for project code. Write ONLY to .majlis/scripts/.
+- Focus on diagnosis, not fixing. Your value is insight, not implementation.
+- Trust the database export over docs/ files when they conflict.`,
+      postmortem: `---
+name: postmortem
+model: opus
+tools: [Read, Glob, Grep]
+---
+You are the Post-Mortem Analyst. You analyze reverted or failed experiments and extract
+structural learnings that prevent future experiments from repeating the same mistakes.
+
+You run automatically when an experiment is reverted. Your job is to produce a specific,
+falsifiable structural constraint that blocks future experiments from repeating the approach.
+
+## What You Receive
+
+- The experiment's hypothesis and metadata
+- Git diff of the experiment branch vs main (what was changed or attempted)
+- The user's reason for reverting (if provided) \u2014 use as a starting point, not the final answer
+- Related dead-ends from the registry
+- Synthesis and fragility docs
+- Optionally: artifact files (sweep results, build logs, etc.) pointed to by --context
+
+## Your Process
+
+1. **Read the context** \u2014 understand what was attempted and why it's being reverted.
+2. **Examine artifacts** \u2014 if --context files are provided, read them. If sweep results,
+   build logs, or metric outputs exist in the working directory, find and read them.
+3. **Analyze the failure** \u2014 determine whether this is structural (approach provably wrong)
+   or procedural (approach might work but was executed poorly or abandoned for other reasons).
+4. **Produce the constraint** \u2014 write a specific, falsifiable structural constraint.
+
+## Constraint Quality
+
+Good constraints are specific and block future repetition:
+- "L6 config space is null \u2014 13-eval Bayesian sweep found all 12 params insensitive (ls=1.27), score ceiling 0.67"
+- "Relaxing curvature split threshold in recursive_curvature_split causes false splits on pure-surface thin strips (seg_pct 95->72.5)"
+- "Torus topology prevents genus-0 assumption for manifold extraction"
+
+Bad constraints are vague and useless:
+- "Didn't work"
+- "Manually reverted"
+- "Needs more investigation"
+
+## Scope
+
+The constraint should clearly state what class of approaches it applies to and what it
+does NOT apply to. For example:
+- "SCOPE: Applies to split threshold changes in Pass 2. Does NOT apply to post-Pass-1 merge operations."
+
+## Output Format
+
+Write a brief analysis (2-5 paragraphs), then output:
+
+<!-- majlis-json
+{
+  "postmortem": {
+    "why_failed": "What was tried and why it failed \u2014 specific, evidence-based",
+    "structural_constraint": "What this proves about the solution space \u2014 blocks future repeats. Include scope.",
+    "category": "structural or procedural"
+  }
+}
+-->
+
+Categories:
+- **structural** \u2014 the approach is provably wrong or the solution space is null. Future experiments
+  that repeat this approach should be rejected by the gatekeeper.
+- **procedural** \u2014 the approach was abandoned for process reasons (e.g., time, priority change,
+  execution error). The approach might still be valid if executed differently.
+
+## Safety Reminders
+- You are READ-ONLY. Do not modify any files.
+- Focus on extracting the constraint, not on suggesting fixes.
+- Trust the evidence in the context over speculation.
+- If you cannot determine the structural constraint from the available context, say so explicitly
+  and categorize as procedural.`
+    };
+    var SLASH_COMMANDS2 = {
+      classify: {
+        description: "Classify a problem domain into canonical sub-types before building",
+        body: `Run \`majlis classify "$ARGUMENTS"\` and follow its output.
+If the CLI is not installed, act as the Builder in classification mode.
+Read docs/synthesis/current.md and docs/synthesis/dead-ends.md for context.
+Enumerate and classify all canonical sub-types of: $ARGUMENTS
+Produce a classification document following docs/classification/_TEMPLATE.md.`
+      },
+      doubt: {
+        description: "Run a constructive doubt pass on an experiment",
+        body: `Run \`majlis doubt $ARGUMENTS\` to spawn the critic agent.
+If the CLI is not installed, act as the Critic directly.
+Doubt the experiment at $ARGUMENTS. Produce a doubt document
+following docs/doubts/_TEMPLATE.md.`
+      },
+      challenge: {
+        description: "Construct adversarial test cases for an experiment",
+        body: `Run \`majlis challenge $ARGUMENTS\` to spawn the adversary agent.
+If the CLI is not installed, act as the Adversary directly.
+Construct pathological inputs designed to break the approach in $ARGUMENTS.
+Produce a challenge document following docs/challenges/_TEMPLATE.md.`
+      },
+      verify: {
+        description: "Verify correctness and provenance of an experiment",
+        body: `Run \`majlis verify $ARGUMENTS\` to spawn the verifier agent.
+If the CLI is not installed, act as the Verifier directly.
+Perform dual verification (provenance + content) on $ARGUMENTS.
+Produce a verification report following docs/verification/_TEMPLATE.md.`
+      },
+      reframe: {
+        description: "Independently reframe a problem from scratch",
+        body: `Run \`majlis reframe $ARGUMENTS\` to spawn the reframer agent.
+If the CLI is not installed, act as the Reframer directly.
+You receive ONLY the problem statement and classification \u2014 NOT builder code.
+Independently decompose $ARGUMENTS and compare with existing classification.`
+      },
+      compress: {
+        description: "Compress project state into dense synthesis",
+        body: `Run \`majlis compress\` to spawn the compressor agent.
+If the CLI is not installed, act as the Compressor directly.
+Read everything. Rewrite docs/synthesis/current.md shorter and denser.
+Update fragility map and dead-end registry.`
+      },
+      scout: {
+        description: "Search externally for alternative approaches",
+        body: `Run \`majlis scout $ARGUMENTS\` to spawn the scout agent.
+If the CLI is not installed, search for alternative approaches to $ARGUMENTS.
+Look for: limitations of current approach, alternative formulations from other fields,
+structurally similar problems in unrelated domains.
+Produce a rihla document at docs/rihla/.`
+      },
+      audit: {
+        description: "Maqasid check \u2014 is the frame right?",
+        body: `Run \`majlis audit "$ARGUMENTS"\` for a purpose audit.
+If the CLI is not installed, review: original objective, current classification,
+recent failures, dead-ends. Ask: is the classification serving the objective?
+Would we decompose differently with what we now know?`
+      },
+      diagnose: {
+        description: "Deep project-wide diagnostic analysis",
+        body: `Run \`majlis diagnose $ARGUMENTS\` for deep diagnosis.
+If the CLI is not installed, perform a deep diagnostic analysis.
+Read docs/synthesis/current.md, fragility.md, dead-ends.md, and all experiments.
+Identify root causes, recurring patterns, evidence gaps, and investigation directions.
+Do NOT modify project code \u2014 analysis only.`
+      },
+      scan: {
+        description: "Scan existing project to auto-detect config and write synthesis",
+        body: `Run \`majlis scan\` to analyze the existing codebase.
+This spawns two agents in parallel:
+- Cartographer: maps architecture \u2192 docs/synthesis/current.md + fragility.md
+- Toolsmith: verifies toolchain \u2192 .majlis/scripts/metrics.sh + config.json
+Use --force to overwrite existing synthesis files.`
+      },
+      resync: {
+        description: "Update stale synthesis after project evolved without Majlis",
+        body: `Run \`majlis resync\` to bring Majlis back up to speed.
+Unlike scan (which starts from zero), resync starts from existing knowledge.
+It assesses staleness, then re-runs cartographer (always) and toolsmith (if needed)
+with the old synthesis and DB history as context.
+Use --check to see the staleness report without making changes.
+Use --force to skip active experiment checks.`
+      }
+    };
+    var HOOKS_CONFIG2 = {
+      hooks: {
+        SessionStart: [
+          {
+            hooks: [
+              {
+                type: "command",
+                command: "majlis status --json 2>/dev/null || true"
+              }
+            ]
+          }
+        ],
+        PreToolUse: [
+          {
+            matcher: "Bash",
+            hooks: [
+              {
+                type: "command",
+                command: "majlis check-commit 2>/dev/null || true",
+                timeout: 10
+              }
+            ]
+          }
+        ],
+        SubagentStop: [
+          {
+            hooks: [
+              {
+                type: "command",
+                command: "echo 'Subagent completed. Run majlis next to continue the cycle.'",
+                timeout: 5
+              }
+            ]
+          }
+        ]
+      }
+    };
+    var DOC_TEMPLATES2 = {
+      "experiments/_TEMPLATE.md": `# Experiment: {{title}}
+
+**Hypothesis:** {{hypothesis}}
+**Branch:** {{branch}}
+**Status:** {{status}}
+**Sub-type:** {{sub_type}}
+**Created:** {{date}}
+
+## Approach
+
+[Describe the approach]
+
+## Decisions
+
+- [evidence_level] Decision description \u2014 justification
+
+## Results
+
+[Describe the results]
+
+## Metrics
+
+| Fixture | Metric | Before | After | Delta |
+|---------|--------|--------|-------|-------|
+| | | | | |
+
+<!-- majlis-json
+{
+  "decisions": [],
+  "grades": []
+}
+-->
+`,
+      "decisions/_TEMPLATE.md": `# Decision: {{title}}
+
+**Evidence Level:** {{evidence_level}}
+**Experiment:** {{experiment}}
+**Date:** {{date}}
+
+## Description
+
+[What was decided]
+
+## Justification
+
+[Why this decision was made, referencing evidence]
+
+## Alternatives Considered
+
+[What else was considered and why it was rejected]
+
+<!-- majlis-json
+{
+  "decisions": [
+    { "description": "", "evidence_level": "", "justification": "" }
+  ]
+}
+-->
+`,
+      "classification/_TEMPLATE.md": `# Classification: {{domain}}
+
+**Date:** {{date}}
+
+## Problem Domain
+
+[Describe the problem domain]
+
+## Sub-Types
+
+### 1. {{sub_type_1}}
+- **Description:**
+- **Canonical form:**
+- **Known constraints:**
+
+### 2. {{sub_type_2}}
+- **Description:**
+- **Canonical form:**
+- **Known constraints:**
+
+## Relationships
+
+[How sub-types relate to each other]
+`,
+      "doubts/_TEMPLATE.md": `# Doubt Document \u2014 Against Experiment {{experiment}}
+
+**Critic:** {{agent}}
+**Date:** {{date}}
+
+## Doubt 1: {{title}}
+
+**Claim doubted:** {{claim}}
+**Evidence level of claim:** {{evidence_level}}
+**Severity:** {{severity}}
+
+**Evidence for doubt:**
+[Specific evidence \u2014 a prior experiment, inconsistency, untested case, or false analogy]
+
+<!-- majlis-json
+{
+  "doubts": [
+    { "claim_doubted": "", "evidence_level_of_claim": "", "evidence_for_doubt": "", "severity": "critical" }
+  ]
+}
+-->
+`,
+      "challenges/_TEMPLATE.md": `# Challenge Document \u2014 Against Experiment {{experiment}}
+
+**Adversary:** {{agent}}
+**Date:** {{date}}
+
+## Challenge 1: {{title}}
+
+**Constructed case:**
+[Specific input or condition designed to break the approach]
+
+**Reasoning:**
+[Why this case should break the approach \u2014 what assumption does it violate?]
+
+## Challenge 2: {{title}}
+
+**Constructed case:**
+[Specific input or condition]
+
+**Reasoning:**
+[Why this should break]
+
+<!-- majlis-json
+{
+  "challenges": [
+    { "description": "", "reasoning": "" }
+  ]
+}
+-->
+`,
+      "verification/_TEMPLATE.md": `# Verification Report \u2014 Experiment {{experiment}}
+
+**Verifier:** {{agent}}
+**Date:** {{date}}
+
+## Provenance Check (Isnad)
+
+| Component | Traceable | Chain intact | Notes |
+|-----------|-----------|--------------|-------|
+| | yes/no | yes/no | |
+
+## Content Check (Matn)
+
+| Component | Tests pass | Consistent | Grade | Notes |
+|-----------|-----------|------------|-------|-------|
+| | yes/no | yes/no | sound/good/weak/rejected | |
+
+## Doubt Resolution
+
+| Doubt | Resolution | Evidence |
+|-------|------------|----------|
+| | confirmed/dismissed/inconclusive | |
+
+<!-- majlis-json
+{
+  "grades": [
+    { "component": "", "grade": "sound", "provenance_intact": true, "content_correct": true, "notes": "" }
+  ],
+  "doubt_resolutions": [
+    { "doubt_id": 0, "resolution": "confirmed" }
+  ]
+}
+-->
+`,
+      "reframes/_TEMPLATE.md": `# Reframe: {{domain}}
+
+**Reframer:** {{agent}}
+**Date:** {{date}}
+
+## Independent Decomposition
+
+[How this problem should be decomposed \u2014 without seeing the builder's approach]
+
+## Natural Joints
+
+[Where does this problem naturally divide?]
+
+## Cross-Domain Analogies
+
+[What analogies from other domains apply?]
+
+## Comparison with Existing Classification
+
+[Structural divergences from the current classification]
+
+## Divergences (Most Valuable Signals)
+
+[Where the independent decomposition differs from the builder's classification]
+`,
+      "rihla/_TEMPLATE.md": `# Rihla (Scout Report): {{topic}}
+
+**Date:** {{date}}
+
+## Problem (Domain-Neutral)
+
+[Describe the problem in domain-neutral terms]
+
+## Alternative Approaches Found
+
+### 1. {{approach}}
+- **Source:**
+- **Description:**
+- **Applicability:**
+
+## Known Limitations of Current Approach
+
+[What external sources say about where this approach fails]
+
+## Cross-Domain Analogues
+
+[Structurally similar problems in unrelated domains]
+`
+    };
+    var DOC_DIRS2 = [
+      "inbox",
+      "experiments",
+      "decisions",
+      "classification",
+      "doubts",
+      "challenges",
+      "verification",
+      "reframes",
+      "rihla",
+      "synthesis",
+      "diagnosis"
+    ];
+    var WORKFLOW_MD2 = `# Majlis Workflow \u2014 Quick Reference
+
+## The Cycle
+
+\`\`\`
+1. CLASSIFY   \u2192 Taxonomy before solution (Al-Khwarizmi)
+2. REFRAME    \u2192 Independent decomposition (Al-Biruni)
+3. GATE       \u2192 Hypothesis quality check ('Ilm al-'Ilal)
+4. BUILD      \u2192 Write code with tagged decisions (Ijtihad)
+5. CHALLENGE  \u2192 Construct breaking inputs (Ibn al-Haytham)
+6. DOUBT      \u2192 Systematic challenge with evidence (Shukuk)
+7. SCOUT      \u2192 External search for alternatives (Rihla)
+8. VERIFY     \u2192 Provenance + content checks (Isnad + Matn)
+9. RESOLVE    \u2192 Route based on grades
+10. COMPRESS  \u2192 Shorter and denser (Hifz)
+\`\`\`
+
+## Resolution
+- **Sound** \u2192 Merge
+- **Good** \u2192 Merge + add gaps to fragility map
+- **Weak** \u2192 Cycle back with synthesised guidance
+- **Rejected** \u2192 Dead-end with structural constraint
+
+## Circuit Breaker
+3+ weak/rejected on same sub-type \u2192 Maqasid Check (purpose audit)
+
+## Evidence Hierarchy
+1. Proof \u2192 2. Test \u2192 3a. Strong Consensus \u2192 3b. Consensus \u2192 4. Analogy \u2192 5. Judgment
+
+## Commands
+| Action | Command |
+|--------|---------|
+| Initialize | \`majlis init\` |
+| Status | \`majlis status\` |
+| New experiment | \`majlis new "hypothesis"\` |
+| Baseline metrics | \`majlis baseline\` |
+| Measure metrics | \`majlis measure\` |
+| Compare metrics | \`majlis compare\` |
+| Next step | \`majlis next\` |
+| Auto cycle | \`majlis next --auto\` |
+| Autonomous | \`majlis run "goal"\` |
+| Session start | \`majlis session start "intent"\` |
+| Session end | \`majlis session end\` |
+| Compress | \`majlis compress\` |
+| Audit | \`majlis audit "objective"\` |
+
+## Experiment Flags
+| Flag | Purpose |
+|------|---------|
+| \`--sub-type TYPE\` | Classify experiment by problem sub-type |
+| \`--depends-on SLUG\` | Block building until dependency is merged |
+| \`--context FILE,FILE\` | Inject domain-specific docs into agent context |
+
+Example: \`majlis new "improve fitting accuracy" --sub-type fitting --depends-on surface-construction --context docs/algorithms/fitting.md,fixtures/anatomy/part1/README.md\`
+
+## Project Readiness
+
+Majlis works with zero config \u2014 agents figure things out from CLAUDE.md. But each
+config field you wire up removes a failure mode and makes cycles more autonomous.
+
+### Metrics Command
+Your \`metrics.command\` must output JSON in this format:
+\`\`\`json
+{ "fixtures": { "fixture_name": { "metric_name": 123.4 } } }
+\`\`\`
+If your test harness outputs human-readable text, write a thin wrapper script that
+parses it into this format. The framework runs this command automatically before and
+after each build to capture regression data.
+
+### Fixtures and Gates
+Define your test cases in \`config.metrics.fixtures\`. Flag your regression baseline
+as a gate \u2014 regressions on gate fixtures block merge regardless of verification grades:
+\`\`\`json
+"fixtures": {
+  "baseline_test": { "gate": true },
+  "target_test": { "gate": false }
+}
+\`\`\`
+
+### Tracked Metrics
+Name the metrics you care about and set their direction:
+\`\`\`json
+"tracked": {
+  "error_rate": { "direction": "lower_is_better" },
+  "accuracy": { "direction": "higher_is_better" },
+  "value_delta": { "direction": "closer_to_gt", "target": 0 }
+}
+\`\`\`
+
+### Architecture Docs
+Agents read CLAUDE.md for project context. The more specific it is about where things
+live, how to build, and how to test, the better agents perform. Include build commands,
+test commands, file layout, and key patterns.
+
+Run \`majlis status\` to see which readiness checks pass and which need attention.
+`;
+    var SYNTHESIS_STARTERS2 = {
+      "current.md": '# Project Synthesis\n\n*No experiments yet. Run `majlis new "hypothesis"` to begin.*\n',
+      "fragility.md": "# Fragility Map\n\n*No fragility recorded yet.*\n",
+      "dead-ends.md": "# Dead-End Registry\n\n*No dead-ends recorded yet.*\n"
+    };
+    var CLAUDE_MD_SECTION = `
+## Majlis Protocol
+
+This project uses the Majlis Framework for structured multi-agent problem solving.
+See \`docs/workflow.md\` for the full cycle. See \`.claude/agents/\` for role definitions (source of truth in \`.majlis/agents/\`).
+
+### Evidence Hierarchy (tag every decision)
+1. **Proof** \u2014 mathematical proof. Overturn requires error in proof.
+2. **Test** \u2014 empirical test. Overturn requires showing test insufficiency.
+3a. **Strong Consensus** \u2014 convergence across independent approaches.
+3b. **Consensus** \u2014 agreement from same-model experiments.
+4. **Analogy** \u2014 justified by similarity to prior work.
+5. **Judgment** \u2014 independent reasoning without precedent.
+
+### Session Discipline
+- One intent per session. Declare it with \`majlis session start "intent"\`.
+- Stray thoughts \u2192 Telegram (Scribe) or docs/inbox/.
+- Every session ends with \`majlis session end\`.
+
+### Before Building
+- Read \`docs/synthesis/current.md\` for compressed project state.
+- Run \`majlis dead-ends --sub-type <relevant>\` for structural constraints.
+- Run \`majlis decisions --level judgment\` for provisional decisions to challenge.
+
+### Compression Trigger
+- Run \`majlis status\` \u2014 it will warn when compression is due.
+
+### Current State
+Run \`majlis status\` for live experiment state and cycle position.
+`;
+    function claudeMdContent2(name, objective) {
+      return `# ${name}
+
+${objective ? `**Objective:** ${objective}
+` : ""}## Majlis Protocol
+
+This project uses the Majlis Framework for structured multi-agent problem solving.
+See \`docs/workflow.md\` for the full cycle. See \`.claude/agents/\` for role definitions (source of truth in \`.majlis/agents/\`).
+
+### Evidence Hierarchy (tag every decision)
+1. **Proof** \u2014 mathematical proof. Overturn requires error in proof.
+2. **Test** \u2014 empirical test. Overturn requires showing test insufficiency.
+3a. **Strong Consensus** \u2014 convergence across independent approaches.
+3b. **Consensus** \u2014 agreement from same-model experiments.
+4. **Analogy** \u2014 justified by similarity to prior work.
+5. **Judgment** \u2014 independent reasoning without precedent.
+
+### Session Discipline
+- One intent per session. Declare it with \`majlis session start "intent"\`.
+- Stray thoughts \u2192 Telegram (Scribe) or docs/inbox/.
+- Every session ends with \`majlis session end\`.
+
+### Before Building
+- Read \`docs/synthesis/current.md\` for compressed project state.
+- Run \`majlis dead-ends --sub-type <relevant>\` for structural constraints.
+- Run \`majlis decisions --level judgment\` for provisional decisions to challenge.
+
+### Compression Trigger
+- Run \`majlis status\` \u2014 it will warn when compression is due.
+
+### Current State
+Run \`majlis status\` for live experiment state and cycle position.
+`;
+    }
+    var DEFAULT_CONFIG = {
+      project: {
+        name: "",
+        description: "",
+        objective: ""
+      },
+      metrics: {
+        command: `echo '{"fixtures":{}}'`,
+        fixtures: {},
+        tracked: {}
+      },
+      build: {
+        pre_measure: null,
+        post_measure: null
+      },
+      cycle: {
+        compression_interval: 5,
+        circuit_breaker_threshold: 3,
+        require_doubt_before_verify: true,
+        require_challenge_before_verify: false,
+        auto_baseline_on_new_experiment: true
+      },
+      models: {
+        builder: "opus",
+        critic: "opus",
+        adversary: "opus",
+        verifier: "opus",
+        reframer: "opus",
+        compressor: "opus",
+        gatekeeper: "sonnet",
+        scout: "opus"
+      }
+    };
+    function configTemplate2(answers) {
+      return JSON.stringify({
+        project: {
+          name: answers.name,
+          description: answers.description,
+          objective: answers.objective
+        },
+        metrics: {
+          command: answers.metricsCommand,
+          fixtures: {},
+          tracked: {}
+        },
+        build: {
+          pre_measure: answers.buildPre || null,
+          post_measure: answers.buildPost || null
+        },
+        cycle: {
+          compression_interval: 5,
+          circuit_breaker_threshold: 3,
+          require_doubt_before_verify: true,
+          require_challenge_before_verify: false,
+          auto_baseline_on_new_experiment: true
+        },
+        models: {
+          builder: "opus",
+          critic: "opus",
+          adversary: "opus",
+          verifier: "opus",
+          reframer: "opus",
+          compressor: "opus",
+          gatekeeper: "sonnet",
+          scout: "opus"
+        }
+      }, null, 2);
+    }
+    var fs3 = __toESM2(require("fs"));
+    function mkdirSafe2(dir) {
+      if (!fs3.existsSync(dir)) {
+        fs3.mkdirSync(dir, { recursive: true });
+      }
+    }
+    function validateProject(checks) {
+      const results = [];
+      results.push(
+        checks.hasGitRepo ? { label: "Git repository", status: "pass", detail: "Detected" } : { label: "Git repository", status: "fail", detail: "Not a git repo \u2014 experiment branches will not work" }
+      );
+      results.push(
+        checks.hasObjective ? { label: "Project objective", status: "pass", detail: "Set in config" } : { label: "Project objective", status: "warn", detail: "Not set \u2014 agents lack goal context for maqasid checks" }
+      );
+      results.push(
+        checks.hasClaudeMd ? { label: "CLAUDE.md", status: "pass", detail: "Found \u2014 agents will have project context" } : { label: "CLAUDE.md", status: "warn", detail: "Not found \u2014 agents will lack project architecture context" }
+      );
+      const hasCommand = checks.metricsCommand && !checks.metricsCommand.includes(`echo '{"fixtures":{}}'`);
+      if (!hasCommand) {
+        results.push({ label: "Metrics command", status: "warn", detail: "Using default no-op \u2014 configure metrics.command for automatic regression detection" });
+      } else if (!checks.metricsCommandRunnable) {
+        results.push({ label: "Metrics command", status: "warn", detail: "Set but not runnable \u2014 check the command works: " + checks.metricsCommand });
+      } else {
+        results.push({ label: "Metrics command", status: "pass", detail: "Set and runnable" });
+      }
+      const fixtureEntries = Array.isArray(checks.fixtures) ? checks.fixtures : Object.keys(checks.fixtures);
+      if (fixtureEntries.length === 0) {
+        results.push({ label: "Fixtures", status: "warn", detail: "None defined \u2014 consider adding fixtures with gate flags for regression protection" });
+      } else {
+        const gateCount = Array.isArray(checks.fixtures) ? 0 : Object.values(checks.fixtures).filter((f) => f.gate).length;
+        if (gateCount === 0) {
+          results.push({ label: "Fixtures", status: "warn", detail: `${fixtureEntries.length} fixture(s) but none flagged as gate \u2014 no regression protection` });
+        } else {
+          results.push({ label: "Fixtures", status: "pass", detail: `${fixtureEntries.length} fixture(s), ${gateCount} gate(s)` });
+        }
+      }
+      const trackedCount = Object.keys(checks.tracked).length;
+      if (trackedCount === 0) {
+        results.push({ label: "Tracked metrics", status: "warn", detail: "None defined \u2014 regression detection disabled" });
+      } else {
+        results.push({ label: "Tracked metrics", status: "pass", detail: `${trackedCount} metric(s) tracked` });
+      }
+      results.push(
+        checks.preMeasure ? { label: "Build command", status: "pass", detail: "Set (pre_measure)" } : { label: "Build command", status: "warn", detail: "No pre_measure \u2014 builder must know how to build from CLAUDE.md" }
+      );
+      results.push(
+        checks.hasSynthesis ? { label: "Synthesis document", status: "pass", detail: "Found" } : { label: "Synthesis document", status: "warn", detail: "Empty \u2014 will be populated after first compression cycle" }
+      );
+      return results;
+    }
+    var _useColor = !process.env.NO_COLOR && process.stderr?.isTTY !== false;
+    function formatValidation(checks) {
+      const lines = [];
+      for (const c of checks) {
+        const icon = c.status === "pass" ? _useColor ? "\x1B[32m\u2713\x1B[0m" : "\u2713" : c.status === "warn" ? _useColor ? "\x1B[33m\u26A0\x1B[0m" : "\u26A0" : _useColor ? "\x1B[31m\u2717\x1B[0m" : "\u2717";
+        lines.push(`  ${icon} ${c.label}: ${c.detail}`);
+      }
+      return lines.join("\n");
+    }
+  }
+});
+
 // src/index.ts
 var fs2 = __toESM(require("fs"));
 var path2 = __toESM(require("path"));
@@ -71,7 +1454,7 @@ function defaultAnswers(projectName) {
 var fs = __toESM(require("fs"));
 var path = __toESM(require("path"));
 var import_node_child_process = require("child_process");
-var import_shared = require("@majlis/shared");
+var import_shared = __toESM(require_dist());
 function scaffold(opts) {
   const { targetDir, answers, fresh, noHooks, minimal } = opts;
   if (fresh) {