chati-dev 4.4.1 → 4.5.2

package/README.md

@@ -73,7 +73,9 @@ The wizard guides you through 4 steps:
 |------|-------------|
 | **Language** | English, Portuguese, Spanish, or French |
 | **Project Type** | Greenfield (new) or Brownfield (existing) |
-| **AI Provider** | Claude, Gemini, or Codex - auto-configures optimal models per agent |
+| **AI Providers** | Select any combination of Claude, Codex, and Grok |
+| **Primary Harness and Models** | Choose the main CLI and the exact signed-catalog models the project may use |
+| **Execution Profile** | Standard, or Focus AI internal with mandatory ClickUp tracking and completion metrics |
 | **Confirm** | Review summary and proceed |
 
 ### 2. Activate the orchestrator
@@ -83,8 +85,8 @@ Open your AI CLI in the same project directory, then type:
 | CLI | Command | Notes |
 |-----|---------|-------|
 | **Claude Code** | `/chati` | Slash command (native) |
-| **Gemini CLI** | `/chati` | TOML custom command |
 | **Codex CLI** | `$chati` | Skill invocation (Codex uses `$` for skills, not `/`) |
+| **Grok CLI** | `/chati` | Native markdown command |
 
 The orchestrator loads your session, detects where you left off, and routes you to the right agent. You stay inside the system until you explicitly exit.
 
@@ -98,8 +100,8 @@ The agents guide you through each phase:
 |-------|-------------|--------|
 | **DISCOVER** | Agents interview you about what you want to build | Answer questions about your project |
 | **PLAN** | Agents create PRD, architecture, UX spec, phases, and tasks | Review and approve the plan |
-| **BUILD** | Dev agent implements the code, task by task | Review code as it's built |
-| **DEPLOY** | DevOps agent handles git, deployment, and documentation | Confirm deployment settings |
+| **RAIL EXECUTION** | Dependency-ready tasks run on their explicitly selected model, with independent review, bounded rework, recovery, and local evidence | Review material scope or authority escalations |
+| **RELEASE** | A sealed release lane checks evidence, Git and CI readiness, with explicit human authorization for external actions | Authorize merge, deployment, or publication |
 
 Quality gates run automatically between phases. If something doesn't meet the threshold, the system loops back and fixes it.
 
@@ -127,18 +129,20 @@ The system saves your full session state (pipeline position, current agent, deci
 | Feature | What it means |
 |---------|--------------|
 | **Specialized Agents** | Each agent has a defined mission, success criteria, and handoff protocol. Not one AI trying to do everything |
-| **Agent Teams** | Planning Team (Detail + Architect + UX + QA-Planning) and Build Team (Dev + QA-Implementation) with Wave-Based Pipeline. Teams work in parallel with peer-to-peer communication, cross-review, and intra-team quality assurance. No single agent bottleneck |
+| **Planning Team** | Detail, Architect, UX, and QA-Planning collaborate on the approved planning artifacts before Tasks seals the RAIL handoff |
+| **RAIL Execution** | Dependency-aware task dispatch, selected-model enforcement, leases, recovery, independent review, two bounded rework cycles, and top-tier adjudication |
 | **Visual QA** | QA-Visual scores the rendered UI against an 8-dimension rubric (layout, typography, motion, interaction, color, spacing, accessibility, performance) with an anti-slop catalog and a spring-motion veto (linear easing and `transition: all` are rejected). Screenshots at multiple scroll positions, hover states, and brandbook compliance, powered by Playwright. |
 | **Premium Motion** | Premium motion is required for UI projects, with cubic-bezier easing and full reduced-motion support. The visual gate is animation-stack aware: the motion-premium presets use GSAP + Lenis, the saas-dashboard preset uses framer-motion. |
 | **Scaffold Presets** | Premium starting points applied at build time: motion-premium and motion-premium-3d for animated showcase sites, saas-dashboard for a token-driven app shell (sidebar, sortable data table, KPI cards, a Cmd+K command palette). |
 | **Execution Kinds** | A task declares how it executes. Deterministic dev tasks (lint, tests, file and schema checks) run as zero-LLM scripts through whitelisted executors instead of spending an agent turn. Feature-flagged, off by default, fully back-compatible. |
-| **Multi-CLI Architecture** | Choose your AI provider at install time: Claude, Gemini, or Codex. Each agent gets the optimal model for that provider |
+| **Multi-CLI Architecture** | Choose Claude, Codex, Grok, or any selected combination. Every invocation is restricted to the provider, harness, model, and reasoning configuration explicitly approved during installation |
 | **Quality Gates** | Every phase is validated before moving forward, including QA-Visual for visual quality. 3-tier verdicts: APPROVED, NEEDS_REVISION, or BLOCKED |
 | **Fault Vector Protocol** | Root Layer Routing classifies bugs by origin (INTENT/SPEC/CODE/DEFER). Evidence-Bound Verdicts, Decision Trail, and Echo Detection prevent cyclical rework |
 | **Context Persistence** | Sessions survive restarts. Close your IDE, come back next week - the system remembers everything |
 | **Session Lock** | Once activated, you stay inside the system. No accidentally "falling out" into generic AI mode |
-| **Multi-Terminal** | Autonomous agents run in parallel. Planning Team (Detail + Architect + UX + QA-Planning) and Build Team (Dev + QA-Implementation) coordinate via peer-to-peer mailbox |
-| **Memory System** | The system learns from mistakes. Gotchas are captured automatically and recalled when relevant |
+| **Multi-Terminal** | RAIL dispatches dependency-ready tasks across the selected harnesses while preserving claim, attempt, review, and completion lineage |
+| **Closed Loop Boundary** | CHATI may read approved Brain context and emit project-local learning candidates. It never writes directly to the Brain |
+| **ClickUp Tracking** | The internal profile requires ClickUp projection through a durable local outbox and keeps Project Evolution as local canonical evidence |
 | **Execution Mode** | Two modes: interactive (default) and autonomous (gate >= 95%). Safety reversion to interactive on stuck loop, quality drop, scope creep, error cascade, or user override (Article XVII) |
 | **IDE-Agnostic** | Works with Claude Code, VS Code, Cursor, Gemini CLI, Codex CLI, and AntiGravity |
 | **4 Languages** | Interface supports English, Portuguese, Spanish, and French. Artifacts are always generated in English |
@@ -207,14 +211,14 @@ The system starts in `interactive` mode. Transition to `autonomous` requires bot
 
 ## Architecture
 
-### Specialized Agents, 4 Pipeline Phases
+### Specialized Agents and RAIL Pipeline
 
 | Phase | Agents | What they do |
 |-------|--------|-------------|
 | **DISCOVER** | Greenfield WU, Brownfield WU, Brief | Interview you, understand your project, extract requirements |
 | **PLAN** | Planning Team (Detail + Architect + UX + QA-Planning), Phases, Tasks | Create PRD, architecture, UX spec with cross-review. QA-Planning validates all 3 artifacts before the team dissolves |
-| **BUILD** | Build Team (Dev + QA-Implementation) with Wave-Based Pipeline. After build: QA-Visual validates visual quality. | Implement code task by task, with per-task quality review and visual validation |
-| **DEPLOY** | DevOps | Handle git operations, deployment, and documentation |
+| **RAIL EXECUTION** | Selected task executors, independent reviewers, browser capability where required | Execute the sealed task graph, collect evidence, recover interrupted attempts, and resolve bounded rework |
+| **RELEASE** | Release lane with human authority gate | Verify readiness and perform no external mutation without explicit authorization |
 
 ### How the Pipeline Works
 
@@ -249,25 +253,23 @@ The system starts in `interactive` mode. Transition to `autonomous` requires bot
        │         │                              │
        │    Then: Phases → Tasks                │
        │                                        │
-       ├─ Spawns Build Team ────────────────────┐
-       │   (2 agents, Wave-Based Pipeline)      │
+       ├─ Seals Planning handoff ───────────────┐
        │                                        │
-       │    BUILD                               │
-       │    Build Waves: Dev + QA in parallel   │
-       │    Cleanup Wave: fixes remaining warns  │
-       │    Visual QA Wave: QA-Visual validates  │
-       │      screenshots, GSAP/Lenis, brandbook │
-       │    Final QA: Triple Review             │
+       │    RAIL EXECUTION                      │
+       │    Dependency-ready task dispatch      │
+       │    Selected model and harness only     │
+       │    Independent review and rework       │
+       │    Recovery, tracking, local evidence  │
        │                                        │
-       └─ Spawns terminal ──────────────────────┐
+       └─ Opens release lane ───────────────────┐
                                                 │
-            DEPLOY                              │
-            DevOps handles git, deploy, docs    │
+            RELEASE                             │
+            Readiness checks and authority gate │
                                                 │
                                          ✓ Done │
 ```
 
-Each spawned terminal runs as a separate CLI process with its own context window, write-scope isolation, and structured handoff output. The AI provider and model are selected automatically based on your configuration.
+Each invocation runs through an installation-selected provider, harness, model, and reasoning configuration. CHATI cannot silently add an unselected provider or model. Existing v4 installations retain the old Build Team and DevOps definitions only for migration compatibility; a sealed v2 handoff can never route into them.
 
 ### Intelligence Layer
 
@@ -426,9 +428,9 @@ your-project/
 │   ├── agents/                   # Agent definitions
 │   │   ├── discover/             # Greenfield WU, Brownfield WU, Brief
 │   │   ├── plan/                 # Detail, Architect, UX, Phases, Tasks
-│   │   ├── quality/              # QA-Planning, QA-Implementation
-│   │   ├── build/                # Dev
-│   │   └── deploy/               # DevOps
+│   │   ├── quality/              # QA-Planning plus legacy compatibility definitions
+│   │   ├── build/                # Legacy v4 compatibility only
+│   │   └── deploy/               # Legacy v4 compatibility only
 │   ├── workflows/                # 7 workflow blueprints
 │   ├── templates/                # 12 artifact templates
 │   ├── schemas/                  # 5 JSON schemas
@@ -493,5 +495,5 @@ For security concerns, see our [Security Policy](.github/SECURITY.md).
 
 <p align="center">
   <sub>Built with structure, validated by agents, governed by constitution.</sub><br>
-  <sub>Chati.dev v4.3.0 "Phoenix" &copy; 2026</sub>
+  <sub>Chati.dev v4.5.1 "Phoenix" &copy; 2026</sub>
 </p>

package/bin/chati.js

@@ -28,6 +28,7 @@ const command = args[0] || 'init';
 const KNOWN_SUBCOMMANDS = new Set([
   // CLI subcommands
   'next', 'advance', 'init', 'status', 'validate-handoff', 'deviation', 'exit',
+  'install-v2', 'migrate-v2', 'rail-import', 'rail-next', 'rail-release-ready', 'rail-claim', 'rail-heartbeat', 'rail-recover', 'rail-complete', 'rail-review', 'rail-tracking-reconcile',
   'providers', 'detect-flow', 'backlog', 'qa-plan-score', 'qa-impl-score', 'scan',
   'spawn-team', 'team-status', 'team-dissolve',
   'stats', 'list', 'search', 'clean', 'check', // memory/registry subcommands
@@ -45,8 +46,11 @@ for (let i = 0; i < args.length; i++) {
     flagValues.add(args[i + 1]);
   }
 }
+const projectDirIndex = args.indexOf('--project-dir');
+const explicitTargetDir = projectDirIndex === -1 ? null : args[projectDirIndex + 1];
 const targetDir = resolve(
-  args.find(a => !a.startsWith('-') && a !== command && !KNOWN_SUBCOMMANDS.has(a) && !flagValues.has(a))
+  explicitTargetDir
+  || args.find(a => !a.startsWith('-') && a !== command && !KNOWN_SUBCOMMANDS.has(a) && !flagValues.has(a))
   || process.cwd()
 );
 
@@ -59,6 +63,236 @@ async function main() {
       break;
     }
 
+    case 'install-v2': {
+      const inputIndex = args.indexOf('--input');
+      const inputPath = inputIndex === -1 ? null : args[inputIndex + 1];
+      if (!inputPath) {
+        console.error('Error: install-v2 requires --input <installation.json>');
+        process.exitCode = 1;
+        break;
+      }
+      let input;
+      try { input = JSON.parse(readFileSync(resolve(inputPath), 'utf8')); } catch (error) {
+        console.error(`Error: cannot read installation input: ${error.message}`);
+        process.exitCode = 1;
+        break;
+      }
+      const { installV2 } = await import('../src/installer-v2/index.js');
+      try {
+        const result = installV2(input, { projectDir: targetDir });
+        console.log(JSON.stringify(result, null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'INSTALL_V2_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'migrate-v2': {
+      const inputIndex = args.indexOf('--input');
+      const inputPath = inputIndex === -1 ? null : args[inputIndex + 1];
+      if (!inputPath) {
+        console.error('Error: migrate-v2 requires --input <installation.json>');
+        process.exitCode = 1;
+        break;
+      }
+      let input;
+      try { input = JSON.parse(readFileSync(resolve(inputPath), 'utf8')); } catch (error) {
+        console.error(`Error: cannot read installation input: ${error.message}`);
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const { migrateV2 } = await import('../src/installer-v2/index.js');
+        const result = migrateV2(input, { projectDir: targetDir, authorize: args.includes('--apply') });
+        console.log(JSON.stringify(result, null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'MIGRATE_V2_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-import': {
+      const handoffIndex = args.indexOf('--handoff');
+      const handoffPath = handoffIndex === -1 ? null : args[handoffIndex + 1];
+      if (!handoffPath) {
+        console.error('Error: rail-import requires --handoff <sealed-handoff.json>');
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const handoff = JSON.parse(readFileSync(resolve(handoffPath), 'utf8'));
+        const { persistRailHandoff } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(persistRailHandoff({ projectDir: targetDir, handoff }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_IMPORT_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-next': {
+      const handoffIndex = args.indexOf('--handoff-id');
+      const handoff_id = handoffIndex === -1 ? null : args[handoffIndex + 1];
+      if (!handoff_id) {
+        console.error('Error: rail-next requires --handoff-id <id>');
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const { selectReadyRailTasks } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(selectReadyRailTasks({ projectDir: targetDir, handoff_id }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_NEXT_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-release-ready': {
+      const handoffIndex = args.indexOf('--handoff-id');
+      const handoff_id = handoffIndex === -1 ? null : args[handoffIndex + 1];
+      if (!handoff_id) {
+        console.error('Error: rail-release-ready requires --handoff-id <id>');
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const { selectRailReleaseReadiness } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(selectRailReleaseReadiness({ projectDir: targetDir, handoff_id }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_RELEASE_READINESS_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-claim': {
+      const value = (flag) => {
+        const index = args.indexOf(flag);
+        return index === -1 ? null : args[index + 1];
+      };
+      const required = ['--handoff-id', '--task-id', '--attempt-id', '--operator-id', '--harness-process-id'];
+      if (required.some((flag) => !value(flag))) {
+        console.error(`Error: rail-claim requires ${required.join(', ')}`);
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const { claimRailTask } = await import('../src/orchestrator/rail-runtime.js');
+      const result = claimRailTask({
+          projectDir: targetDir, handoff_id: value('--handoff-id'), task_id: value('--task-id'), attempt_id: value('--attempt-id'),
+          operator_id: value('--operator-id'), harness_process_id: value('--harness-process-id'), git_dir: value('--git-dir') || targetDir,
+        });
+        console.log(JSON.stringify(result, null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_CLAIM_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-heartbeat': {
+      const value = (flag) => { const index = args.indexOf(flag); return index === -1 ? null : args[index + 1]; };
+      const required = ['--handoff-id', '--attempt-id', '--claim-id', '--operator-id'];
+      if (required.some((flag) => !value(flag))) {
+        console.error(`Error: rail-heartbeat requires ${required.join(', ')}`);
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const { heartbeatRailTask } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(heartbeatRailTask({
+          projectDir: targetDir, handoff_id: value('--handoff-id'), attempt_id: value('--attempt-id'),
+          claim_id: value('--claim-id'), operator_id: value('--operator-id'),
+        }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_HEARTBEAT_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-recover': {
+      const value = (flag) => { const index = args.indexOf(flag); return index === -1 ? null : args[index + 1]; };
+      const required = ['--handoff-id', '--attempt-id', '--operator-id', '--harness-process-id', '--reconciliation'];
+      if (required.some((flag) => !value(flag))) {
+        console.error(`Error: rail-recover requires ${required.join(', ')}`);
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const reconciliation = JSON.parse(readFileSync(resolve(value('--reconciliation')), 'utf8'));
+        const { recoverRailTask } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(recoverRailTask({
+          projectDir: targetDir, handoff_id: value('--handoff-id'), attempt_id: value('--attempt-id'),
+          operator_id: value('--operator-id'), harness_process_id: value('--harness-process-id'), reconciliation,
+          git_dir: value('--git-dir') || targetDir,
+        }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_RECOVERY_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-complete': {
+      const value = (flag) => { const index = args.indexOf(flag); return index === -1 ? null : args[index + 1]; };
+      if (!value('--handoff-id') || !value('--completion')) {
+        console.error('Error: rail-complete requires --handoff-id <id> and --completion <completion.json>');
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const completion = JSON.parse(readFileSync(resolve(value('--completion')), 'utf8'));
+        const { completeRailTask } = await import('../src/orchestrator/rail-runtime.js');
+        const { completion_id, attempt_id, claim_id, operator_id, state, git, ci, reviews, acceptance_evidence_refs, completed_at, metrics } = completion;
+        console.log(JSON.stringify(completeRailTask({
+          projectDir: targetDir, handoff_id: value('--handoff-id'), completion_id, attempt_id, claim_id, operator_id, state, git, ci,
+          reviews, acceptance_evidence_refs, ...(completed_at === undefined ? {} : { completed_at }), ...(metrics === undefined ? {} : { metrics }),
+        }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_COMPLETION_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-tracking-reconcile': {
+      const value = (flag) => { const index = args.indexOf(flag); return index === -1 ? null : args[index + 1]; };
+      try {
+        const { reconcileProjectClickUpTracking } = await import('../src/orchestrator/rail-runtime.js');
+        console.log(JSON.stringify(reconcileProjectClickUpTracking({
+          projectDir: targetDir,
+          ...(value('--handoff-id') ? { handoff_id: value('--handoff-id') } : {}),
+        }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_TRACKING_RECONCILIATION_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
+    case 'rail-review': {
+      const value = (flag) => { const index = args.indexOf(flag); return index === -1 ? null : args[index + 1]; };
+      if (!value('--review') || !value('--invocation')) {
+        console.error('Error: rail-review requires --review <review.json> and --invocation <invocation.json>');
+        process.exitCode = 1;
+        break;
+      }
+      try {
+        const review = JSON.parse(readFileSync(resolve(value('--review')), 'utf8'));
+        const invocation = JSON.parse(readFileSync(resolve(value('--invocation')), 'utf8'));
+        const { recordRailReview } = await import('../src/orchestrator/review-runtime.js');
+        console.log(JSON.stringify(recordRailReview({ projectDir: targetDir, review, invocation }), null, 2));
+      } catch (error) {
+        console.error(`Error: ${error.code || 'RAIL_REVIEW_FAILED'}: ${error.message}`);
+        process.exitCode = 1;
+      }
+      break;
+    }
+
     case 'status': {
       const watchFlag = args.includes('--watch') || args.includes('-w');
       const { renderDashboard, renderDashboardWatch } = await import('../src/dashboard/renderer.js');

package/framework/agents/plan/tasks.md

@@ -26,7 +26,7 @@ You are the **Tasks Agent**, responsible for breaking phases into atomic, execut
 
 ## Mission
 
-Create atomic, testable, estimable tasks for each phase. Every task has a clear title, acceptance criteria in Given-When-Then format, size estimate, dependencies, and traces back to a PRD requirement. These tasks become the execution instructions for the Dev agent.
+Create atomic, testable, estimable tasks for each phase. Every task has a clear title, acceptance criteria in Given-When-Then format, size estimate, dependencies, and traces back to a PRD requirement. These tasks become an immutable execution handoff for the internal RAIL engine. After that handoff is sealed, CHATI does not enter the legacy Build Team or DevOps flow.
 
 ---
 
@@ -204,6 +204,51 @@ Document findings and fix before presenting to user.
 Validate all criteria, present to user for approval
 ```
 
+### Step 5: Produce the RAIL task graph
+
+When the project has a v2 installation, write the machine-readable task graph
+to `.chati/v2/planning/tasks.json`. This file is required before the Tasks
+agent can advance. It is the source used to create the sealed RAIL handoff.
+
+```json
+{
+  "version": "1.0.0",
+  "source_artifacts": {
+    "requirements_path": "artifacts/2-PRD/prd.md",
+    "architecture_path": "artifacts/3-Architecture/architecture.md",
+    "qa_plan_path": "artifacts/7-QA/qa-plan.md"
+  },
+  "tasks": [{
+    "id": "T1.1",
+    "dependencies": [],
+    "criteria": [{ "given": "the approved project baseline", "when": "the task is executed", "then": "the stated, verifiable outcome exists" }],
+    "execution_scope_ref": "artifact://task-scope/T1.1",
+    "routing_constraints_ref": "policy://routing/T1.1",
+    "execution_binding": {
+      "provider_id": "openai",
+      "harness_id": "codex",
+      "model_id": "the-model-selected-during-installation",
+      "reasoning_configuration": "high"
+    },
+    "clickup_ref": "clickup://task/T1.1",
+    "estimate": {
+      "ai_processing": { "unit": "minutes", "value": 30 },
+      "human_effort": { "unit": "minutes", "value": 10 },
+      "uncertainty": "medium"
+    },
+    "requires_browser": false
+  }]
+}
+```
+
+Rules:
+
+- Preserve the same task IDs, dependencies and Given-When-Then criteria in the prose artifact and JSON task graph.
+- `clickup_ref` is mandatory for the internal profile. It is an opaque mapping, not permission to mutate ClickUp directly.
+- `execution_binding` is mandatory. Select only a provider, harness, model and reasoning configuration present in `.chati/v2/installation.json`; choose the best eligible binding for that task. Never name an unselected vendor or rely on the primary harness as an implicit fallback.
+- If `requires_browser` is true, provide a complete task-specific `browser_policy`. A global MCP configuration is not sufficient.
+- Do not infer missing execution scope, estimates, dependencies, ClickUp refs or browser policy. Return to planning and make the information explicit.
+
 ---
 
 ## Task Sizing Guide

package/framework/config.yaml

@@ -1,8 +1,8 @@
 # chati.dev Configuration
-version: "4.4.1"
+version: "4.5.2"
 installed_at: "2026-02-07T10:00:00Z"
 updated_at: "2026-06-11T00:00:00Z"
-installer_version: "4.4.1"
+installer_version: "4.5.2"
 project_type: greenfield
 language: en
 ides: [claude-code]

package/framework/constitution.md

@@ -446,16 +446,13 @@ The orchestrator SHALL select the optimal AI model for each agent to balance qua
 
 8. Model selections are logged in session.yaml under `model_selections[]` for cost tracking and optimization.
 
-9. Three provider categories are recognized for multi-CLI execution:
-   - **claude**: Primary provider. Deep reasoning, complex analysis, code generation. Full hook support, MCP support.
-   - **gemini**: Large-context provider. Codebase analysis, discovery, document review. 1M token context window. Full hook support, MCP support.
-   - **codex**: Rapid-coding provider. Fast code generation, sandbox execution. No hook support, MCP support.
+9. The initial multi-CLI bindings are **claude**, **codex**, and **grok**. An installation explicitly records its enabled providers, models, primary harness and time-bounded capability snapshot in `.chati/v2/installation.json`.
 
-10. Claude is the default and primary provider. Multi-CLI is opt-in via `config.yaml` `providers` section. When only `claude` is enabled, the system behaves identically to v2.x.
+10. The primary harness is selected during installation. No vendor has a framework-wide primary status.
 
-11. Provider assignments per agent are defined in `config.yaml` under `agent_overrides`. When no override exists, the agent uses the primary provider.
+11. Every invocation MUST resolve to an enabled provider and one of its explicitly allowed models. A missing, unavailable or expired binding is a controlled block. The system MUST NOT silently substitute another provider, model or primary harness.
 
-12. For providers without hook support (e.g., codex), governance is enforced by prompt injection — the PRISM context block is embedded in the prompt rather than injected via hooks. This provides softer but functional governance.
+12. Provider-specific capabilities may change the adapter mechanics, but not the execution contract. Where hooks are unavailable, the equivalent policy is carried through the signed invocation context and verified receipts.
 
 **Enforcement: GUIDE** — Model recommendations are advisory in IDE mode; automatic in SDK mode.
 
@@ -485,7 +482,7 @@ The system SHALL support two execution modes that govern the degree of human inv
 
 6. Safety net triggers SHALL pause autonomous execution when dangerous conditions are detected: consecutive failures, circular approaches, resource limits, or destructive operations.
 
-7. Loop protection: the pipeline manager tracks consecutive correction cycles for each reviewer-to-rework-target pair. Once the correction-cycle limit at the same pipeline point is exceeded (default: 2 cycles, so the third consecutive failure), the system SHALL stop the correction loop and escalate to human review regardless of mode.
+7. Loop protection: the pipeline manager tracks consecutive correction cycles for each reviewer-to-rework-target pair. Two normal correction cycles are allowed. A third consecutive failure SHALL use the installation-selected top-tier adjudication route before a human escalation. Human escalation is reserved for authority decisions, unresolved scope or conflicting evidence.
 
 8. Mode transitions are logged in session.yaml under `mode_transitions[]` for audit trail.
 
@@ -530,21 +527,21 @@ When multiple CLI providers are enabled, the system SHALL coordinate agent execu
 
 2. The handoff format is provider-agnostic. All agents, regardless of which CLI executes them, produce handoffs in the same two-layer format (Article VIII). This ensures consistent inter-provider communication without format translation.
 
-3. Provider availability SHALL be validated by the health check engine before spawning. If a configured provider is unavailable, the system SHALL fall back to the primary provider (claude) with a warning.
+3. Provider availability SHALL be validated before spawning. If a selected provider or model is unavailable, the affected task is blocked with evidence. The system SHALL NOT fall back to another provider or model.
 
-4. Context file generation is automatic. When a provider is enabled in `config.yaml`, the installer SHALL generate the corresponding context file (GEMINI.md for gemini, AGENTS.md for codex) derived from CLAUDE.md content.
+4. Context file generation is adapter-specific. The installer SHALL generate only the integration artifacts required by the selected Claude, Codex and Grok harnesses.
 
 5. Hook-based governance (constitution-guard, mode-governance, read-protection) applies ONLY to providers with hook support. For providers without hooks, equivalent governance is enforced via prompt injection — the PRISM context block includes governance directives.
 
-6. The orchestrator SHALL select the optimal provider for each agent based on:
-   a. Agent's provider preference (defined in agent Identity section)
-   b. Project-level overrides (config.yaml `agent_overrides`)
-   c. Provider availability (health check)
-   d. Fallback: primary provider (claude)
+6. The orchestrator SHALL select the optimal binding only from the installation allow-list, based on:
+   a. Task routing constraints and required capabilities
+   b. The selected model catalog snapshot
+   c. The primary harness only when it is itself an allowed binding
+   d. Availability evidence, otherwise a controlled block
 
 7. Cost tracking SHALL include provider information. Each model selection entry in session.yaml includes: provider, model, agent, timestamp, and estimated token usage.
 
-**Enforcement: GUIDE** — Provider selection is advisory. The system falls back gracefully when providers are unavailable.
+**Enforcement: BLOCK** — Provider and model selection is an installation contract, not an advisory preference.
 
 ---
 

package/framework/context/governance.md

@@ -43,7 +43,7 @@ Extracted from `chati.dev/constitution.md` (25 Articles). Read the full constitu
 - Controls whether human or system makes pipeline decisions
 - Autonomous mode requires gate score >= 95% (qa-planning >= 95%, qa-implementation >= 95%)
 - Safety reversion (Article XVII): the orchestrator reverts autonomous to interactive on a stuck loop. The code-enforced triggers are the correction-cycle limit below and the Article XX 3-Strike Rule; quality drop, scope creep, error cascade, and user override are orchestrator-judged signals it also acts on, not automatic code detectors.
-- Loop protection: consecutive correction cycles per reviewer/rework-target pair; escalate to human once the limit (default 2) is exceeded
+- Loop protection: two normal correction cycles, then top-tier AI adjudication. Escalate to a human only for an authority decision, unresolved scope or conflicting evidence.
 - Git authority: while a pipeline is active, only the devops agent may push to a remote or open a pull request (`git-push-authority` hook, PreToolUse Bash); other agents are denied with a clear message. Outside an active pipeline, git is unaffected.
 - Surface criteria: even in autonomous mode, a high-stakes transition (deploy is external and irreversible) requires a human nod before proceeding; passing the quality gates alone does not auto-confirm it. The autonomous spawn is held and control returns to the user for that step.
 
@@ -53,10 +53,10 @@ Extracted from `chati.dev/constitution.md` (25 Articles). Read the full constitu
 - New code SHALL use `execution_mode` only (interactive | autonomous). Do NOT add new references to `execution_profile`.
 
 ## Multi-CLI Governance (Article XIX)
-- 3 providers: Claude, Gemini, Codex
-- Provider selected at install time, auto-configures optimal models per agent
-- Resolution chain: agent_overrides > agent default > primary provider
-- Context files auto-generated for non-Claude providers (GEMINI.md, AGENTS.md)
+- Initial providers: Claude, Codex, Grok
+- Provider, exact models and primary harness are selected at installation and recorded in `.chati/v2/installation.json`
+- Resolution is restricted to the installation allow-list. An unavailable binding blocks the task, it never falls back silently.
+- Adapter-specific context files are generated only for the selected harnesses.
 
 ## Anti-Loop Protocol (Article XX)
 - 3-Strike Rule: 3 edits to same file without resolution = STOP

package/framework/context/root.md

@@ -1,11 +1,11 @@
 # Chati.dev System Context
 
 ## Framework
-- **Version**: 4.4.0
-- **Agents**: Specialized agents across DISCOVER, PLAN, BUILD, DEPLOY phases
+- **Version**: 4.5.2
+- **Agents**: Specialized discovery and planning agents feeding provider-neutral RAIL execution and a sealed release lane
 - **Constitution**: 25 Articles + Preamble
 - **Quality**: 5 pipeline gates + 3-tier verdicts + Fault Vector Protocol (Article XXII)
-- **Agent Teams**: Native Claude Code teams with peer communication (Article XXI, default ON for Claude provider)
+- **Provider Policy**: Claude, Codex, and Grok bindings are selected at installation and enforced per task
 
 ## Key References
 - **Session State**: `.chati/session.yaml` (runtime, not committed)
@@ -18,8 +18,8 @@
 ```
 DISCOVER: WU -> Brief
 PLAN:     [Planning Team: Detail + Architect + UX + QA-Planning] -> Phases -> Tasks
-BUILD:    [Build Team: Dev + QA-Implementation] -> QA-Visual
-DEPLOY:   DevOps
+RAIL:     Sealed task graph -> Execute -> Independent Review -> Bounded Rework
+RELEASE:  Evidence gate -> Explicit human authorization -> External action
 ```
 
 ## How to Use

package/framework/i18n/en.yaml

@@ -22,8 +22,14 @@ installer:
   llm_provider_not_installed: "(CLI not detected)"
   llm_provider_label: "AI Provider"
   ide_selection_title: "Select your IDEs / CLIs (multiple allowed):"
-  primary_provider_title: "Which is your primary CLI provider?"
-  primary_provider_label: "Primary Provider"
+  installation_mode_title: "Select the installation mode"
+  installation_mode_open: "Open"
+  installation_mode_open_hint: "Public framework without mandatory company integrations"
+  installation_mode_internal: "Internal"
+  installation_mode_internal_hint: "Requires an authorized license and enables ClickUp tracking plus internal policies"
+  installation_mode_label: "Installation mode"
+  model_routing_label: "Model routing"
+  model_routing_automatic: "Automatic per task across all enabled models"
   providers_label: "Providers"
   quick_start_switch_hint: "Switch CLIs anytime — your session continues from where you left off"
   created_overlays: "Created provider overlay directories"

package/framework/i18n/es.yaml

@@ -22,8 +22,14 @@ installer:
   llm_provider_not_installed: "(CLI no detectada)"
   llm_provider_label: "Proveedor de IA"
   ide_selection_title: "Seleccione sus IDEs / CLIs (multiples permitidos):"
-  primary_provider_title: "Cual es su proveedor CLI principal?"
-  primary_provider_label: "Proveedor Principal"
+  installation_mode_title: "Seleccione el modo de instalacion"
+  installation_mode_open: "Open"
+  installation_mode_open_hint: "Framework publico sin integraciones corporativas obligatorias"
+  installation_mode_internal: "Internal"
+  installation_mode_internal_hint: "Requiere una licencia autorizada y activa el tracking en ClickUp y las politicas internas"
+  installation_mode_label: "Modo de instalacion"
+  model_routing_label: "Enrutamiento de modelos"
+  model_routing_automatic: "Automatico por tarea entre todos los modelos habilitados"
   providers_label: "Proveedores"
   quick_start_switch_hint: "Cambie de CLI en cualquier momento — su sesion continua desde donde quedo"
   created_overlays: "Creados directorios de overlay de proveedores"