chati-dev 4.1.1 → 4.1.3

package/README.md

@@ -374,7 +374,7 @@ your-project/
 │   ├── commands/
 │   │   └── chati.toml            # TOML command → orchestrator
 │   ├── context/                  # 4 framework context files (@imported by GEMINI.md)
-│   ├── hooks/                    # 8 hooks (full governance parity with Claude Code)
+│   ├── hooks/                    # Gemini hooks (governance parity with Claude Code)
 │   ├── settings.json             # Hook configuration
 │   └── session-lock.md           # Runtime state / session lock (gitignored)
 ├── GEMINI.md                     # Project context with @import chain
@@ -400,7 +400,7 @@ your-project/
 │   ├── schemas/                  # 5 JSON schemas
 │   ├── intelligence/             # PRISM, RECALL, COMPASS specs
 │   ├── domains/                  # Per-agent and per-workflow configs
-│   ├── hooks/                    # 9 shared hooks (used by Claude + Gemini)
+│   ├── hooks/                    # Shared hooks (used by Claude + Gemini)
 │   ├── context/                  # Context files (deployed per provider)
 │   ├── frameworks/               # Decision heuristics
 │   ├── quality-gates/            # Planning & implementation gates

package/framework/agents/build/dev.md

@@ -156,14 +156,14 @@ WHILE tasks_pending:
          → If no architecture.md → proceed with best practices
     3. Implement code
        -> Output: "T{X} implementation done. Self-critique (5.5)..."
-    3. Run self-critique (Step 5.5) — 1 fix pass, then proceed
+    4. Run self-critique (Step 5.5) — 1 fix pass, then proceed
        -> Output: "T{X} critique done. Running tests..."
-    4. Run tests (once)
+    5. Run tests (once)
        -> Output: "T{X} tests: {N}/{total} passed. Post-test review (6.5)..."
-    5. Run post-test critique (Step 6.5) — 1 fix pass, then score
+    6. Run post-test critique (Step 6.5) — 1 fix pass, then score
        -> Output: "T{X} review done. Scoring..."
-    6. Self-validate against acceptance criteria
-    7. Calculate score
+    7. Self-validate against acceptance criteria
+    8. Calculate score
 
     IF score >= 95:
       mark_complete(task)

package/framework/agents/plan/architect-data-engineer.md

@@ -260,6 +260,14 @@ Strategy (based on data criticality from PRD):
 
 ---
 
+## Output Artifact
+
+Write your complete output to: `chati.dev/artifacts/3-Architecture/data-architecture.md`
+
+This file is the human-reviewable data architecture document. It will also be merged into the consolidated `architecture.md` by the Architect Manager.
+
+---
+
 ## Self-Validation (6 criteria, threshold >= 90%)
 
 1. Schema covers all PRD entities with proper normalization (3NF minimum)

package/framework/agents/plan/architect-system.md

@@ -155,6 +155,14 @@ For each OWASP category, document the mitigation strategy:
 
 ---
 
+## Output Artifact
+
+Write your complete output to: `chati.dev/artifacts/3-Architecture/system-architecture.md`
+
+This file is the human-reviewable system architecture document. It will also be merged into the consolidated `architecture.md` by the Architect Manager.
+
+---
+
 ## Self-Validation (7 criteria, threshold >= 90%)
 
 1. Tech stack selected and justified with exact version numbers

package/framework/agents/plan/architect.md

@@ -95,7 +95,14 @@ If mismatches found: route correction to the responsible sub-agent.
 
 ### Step 4: Consolidate & Handoff
 
-1. Merge outputs into unified `architecture.md` with 10 sections:
+Each sub-agent writes its own artifact first (human-reviewable), then the Manager consolidates.
+
+**Sub-agent artifacts (written by each sub-agent):**
+- System Architect writes: `chati.dev/artifacts/3-Architecture/system-architecture.md`
+- Data Engineer writes: `chati.dev/artifacts/3-Architecture/data-architecture.md`
+
+**Consolidated artifact (written by Manager):**
+Merge both into `chati.dev/artifacts/3-Architecture/architecture.md` with 10 sections:
    - Section 1: Architecture Overview
    - Section 2: Tech Stack (table with versions and justifications)
    - Section 3: System Components (diagram, patterns)
@@ -107,6 +114,14 @@ If mismatches found: route correction to the responsible sub-agent.
    - Section 9: Scalability
    - Section 10: Architecture Decision Records (ADRs)
 
+The consolidated file is what downstream agents (UX, Dev) consume.
+The individual files are for human review and approval.
+
+**Verification**: After consolidation, confirm all 3 files exist:
+```
+ls chati.dev/artifacts/3-Architecture/system-architecture.md chati.dev/artifacts/3-Architecture/data-architecture.md chati.dev/artifacts/3-Architecture/architecture.md
+```
+
 2. Verify all self-validation criteria pass (>= 90%)
 3. Generate handoff for UX agent
 
@@ -136,7 +151,9 @@ Score = criteria met / 10. Threshold: >= 90% (9/10 minimum).
 
 | Artifact | Owner | Mandatory |
 |----------|-------|-----------|
-| `chati.dev/artifacts/3-Architecture/architecture.md` | All (consolidated by Manager) | Yes |
+| `chati.dev/artifacts/3-Architecture/system-architecture.md` | System Architect | Yes |
+| `chati.dev/artifacts/3-Architecture/data-architecture.md` | Data Engineer | Yes |
+| `chati.dev/artifacts/3-Architecture/architecture.md` | Manager (consolidated) | Yes |
 
 ---
 

package/framework/agents/plan/ux-brand-architect.md

@@ -98,7 +98,9 @@ Output: `chati.dev/artifacts/4-UX/reference-analysis.md`
 ### Brandbook Outputs
 
 Output: `chati.dev/artifacts/4-UX/brandbook.md`
-Output: `chati.dev/artifacts/4-UX/brandbook.html` (MANDATORY)
+Output: `chati.dev/artifacts/4-UX/brandbook.html` (MANDATORY — BLOCKS HANDOFF IF MISSING)
+
+**CRITICAL: The brandbook.html is NOT optional.** Without it, the brandbook is just text describing colors — the user cannot visually validate the design system. This file MUST be written to disk before self-validation. If you skip it, the handoff WILL fail.
 
 The brandbook.html is a standalone visual style guide with all CSS inline.
 It MUST render all design tokens visually across 14 sections:
@@ -115,6 +117,12 @@ Requirements:
 - Uses ONLY the design tokens defined in brandbook.md
 - No emojis, no placeholder content
 
+**Verification**: After writing, confirm the file exists:
+```
+ls chati.dev/artifacts/4-UX/brandbook.html
+```
+If the file does not exist, you have NOT completed this phase. Write it before proceeding.
+
 ---
 
 ## Phase 4: Design System Definition
@@ -203,7 +211,7 @@ Hardcoded values are never acceptable, even in prototyping.
 5. Tokenization coverage >= 95%
 6. Reference benchmarking completed (5 permanent + user-provided)
 7. Visual direction unique (font, color, layout archetype differ from references)
-8. Brandbook HTML produced as standalone file with all 14 sections
+8. **[BLOCKER]** Brandbook HTML file exists at `chati.dev/artifacts/4-UX/brandbook.html` with all 14 sections rendered visually. If this file does not exist on disk, score is capped at 0% regardless of other criteria.
 9. No placeholders in any output
 
 ---

package/framework/config.yaml

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

package/framework/constitution.md

@@ -276,11 +276,11 @@ The pipeline operates in three execution modes that control agent permissions. M
 
 1. The orchestrator SHALL calculate the context bracket (FRESH, MODERATE, DEPLETED, CRITICAL) before every agent interaction.
 
-2. Context injection layers SHALL be reduced according to bracket level:
-   - FRESH: All 6 layers (L0-L5)
-   - MODERATE: L0 + L1 + L2 + L3 + L5 (skip L4 task detail)
-   - DEPLETED: L0 (Constitution) + L1 (Mode) + L2 (Agent) only
-   - CRITICAL: L0 (Constitution) + L1 (Mode) only
+2. Context injection layers SHALL INCREASE as context depletes (Progressive Reinforcement):
+   - FRESH: L0 (Constitution) + L1 (Global) only — model has full memory, minimal reinforcement
+   - MODERATE: L0 + L1 + L2 (Agent) + L3 (Workflow) — model starting to forget
+   - DEPLETED: All 6 layers (L0-L5) — significant context loss, full reinforcement
+   - CRITICAL: All 6 layers (L0-L5) + forced handoff — maximum reinforcement, do not accept degraded output
 
 3. Context recovery uses a two-level autonomous strategy:
    a. Level 1 (Smart Continuation): When context is compacted, the orchestrator SHALL automatically capture a digest, persist memories, and rebuild context post-compact. The user experiences zero interruption.
@@ -424,11 +424,13 @@ The system SHALL support two execution modes that govern the degree of human inv
    - **brief**: Requirements extraction requires human validation
    - **orchestrator (deviation protocol)**: Deviations from the plan always need human approval
 
-5. Safety net triggers SHALL pause autonomous execution when dangerous conditions are detected: consecutive failures, circular approaches, resource limits, or destructive operations.
+5. **Terminology Note:** "Autonomous" in this article controls WHO evaluates gates (system vs human). Article XVIII's "autonomous" profile controls WHETHER confirmation is required for writes. Both must be satisfied for fully autonomous operation: this article's mode active AND Article XVIII cumulative gate score >= 95%.
 
-6. Circuit breaker pattern: After 3 consecutive gate failures at the same pipeline point, the system SHALL pause and escalate to human review regardless of mode.
+6. Safety net triggers SHALL pause autonomous execution when dangerous conditions are detected: consecutive failures, circular approaches, resource limits, or destructive operations.
 
-7. Mode transitions are logged in session.yaml under `mode_transitions[]` for audit trail.
+7. Circuit breaker pattern: After 3 consecutive gate failures at the same pipeline point, the system SHALL pause and escalate to human review regardless of mode.
+
+8. Mode transitions are logged in session.yaml under `mode_transitions[]` for audit trail.
 
 **Enforcement: STRICT** — Autonomous mode MUST NOT bypass quality gates. All agents MUST respect the configured thresholds.
 
@@ -487,5 +489,5 @@ When multiple CLI providers are enabled, the system SHALL coordinate agent execu
 
 ---
 
-*Chati.dev Constitution v4.1.1 — 19 Articles + Preamble*
+*Chati.dev Constitution v4.1.3 — 19 Articles + Preamble*
 *All agents are bound by this Constitution. Violations are enforced per article.*

package/framework/context/root.md

@@ -1,7 +1,7 @@
 # Chati.dev System Context
 
 ## Framework
-- **Version**: 4.1.1
+- **Version**: 4.1.3
 - **Agents**: Specialized agents across DISCOVER, PLAN, BUILD, DEPLOY phases
 - **Constitution**: 19 Articles + Preamble
 - **Quality**: 5 pipeline gates + 3-tier verdicts (APPROVED / NEEDS_REVISION / BLOCKED)

package/framework/data/entity-registry.yaml

@@ -3,8 +3,8 @@
 # and by the Health Check for system integrity validation.
 
 metadata:
-  version: "4.1.0"
-  last_updated: "2026-04-02T00:00:00Z"
+  version: "4.1.3"
+  last_updated: "2026-04-06T00:00:00Z"
   entity_count: 62
   checksum_algorithm: sha256
 

package/framework/domains/global.yaml

@@ -79,10 +79,10 @@ modes:
 
 brackets:
   FRESH:
-    behavior: "Moderate context injection. All layers active but model is warming up. Budget lower than MODERATE."
+    behavior: "Minimal reinforcement. L0+L1 only. Model has full memory, no need to re-inject context."
   MODERATE:
-    behavior: "Peak context injection. Maximum token budget. Model has context and needs maximum reinforcement."
+    behavior: "Growing reinforcement. L0-L3 active. Model starting to forget initial instructions."
   DEPLETED:
-    behavior: "Reduced injection. Only L0+L1+L2. Use rule IDs instead of full text."
+    behavior: "Full reinforcement. All 6 layers (L0-L5) active. Significant context loss, compensate with maximum injection."
   CRITICAL:
-    behavior: "Emergency. L0+L1 only. Trigger handoff advisory. Preserve essential state."
+    behavior: "Emergency reinforcement. All 6 layers (L0-L5) active. Trigger handoff. Do not accept degraded output."

package/framework/hooks/constitution-guard.js

@@ -140,7 +140,7 @@ const SHELL_INJECTION_CHECKS = [
   { id: 'JQ_SYSTEM_FUNCTION', pattern: /jq\b.*\bsystem\s*\(/i, severity: 'critical' },
   { id: 'JQ_FILE_ARGUMENTS', pattern: /jq\b.*--from-file|jq\b.*-f\s+[^|&;]+/i, severity: 'high' },
   { id: 'OBFUSCATED_FLAGS', pattern: /\$[({].*[)}].*-/, severity: 'high' },
-  { id: 'SHELL_METACHARACTERS', pattern: /[`]|(?:\$\((?!.*\becho\b))/, severity: 'critical' },
+  { id: 'SHELL_METACHARACTERS', pattern: /[`]|\$\(/, severity: 'critical' },
   { id: 'DANGEROUS_VARIABLES', pattern: /(?:^|\s)(?:PATH|LD_PRELOAD|LD_LIBRARY_PATH|DYLD_INSERT_LIBRARIES|PYTHONPATH|NODE_PATH|RUBYLIB|PERL5LIB)\s*=/, severity: 'critical' },
   { id: 'NEWLINES', pattern: /(?<!\\)\n.*(?:rm|curl|wget|chmod|chown|sudo|eval|exec)/, severity: 'high' },
   { id: 'BACKSLASH_ESCAPED_WHITESPACE', pattern: /\\\s+(?:-|\/)/,severity: 'medium' },

package/framework/hooks/prism-engine.js

@@ -79,16 +79,17 @@ async function main() {
       return 200_000;
     }
 
+    // Primary: turn-count tracks cumulative context consumption across the session.
+    // Fallback: prompt-length for first turn or missing session data.
     let remainingPercent;
-    const promptText = event.prompt || '';
-    if (promptText.length > 0) {
+    const maxTurns = 40;
+    if (session.turnCount > 0) {
+      remainingPercent = Math.max(0, Math.round((1 - session.turnCount / maxTurns) * 100));
+    } else {
+      const promptText = event.prompt || '';
       const estimatedTokens = Math.ceil(promptText.length / 4);
       const contextLimit = hookResolveLimit(inferredModel, session.provider);
       remainingPercent = Math.max(0, Math.round((1 - estimatedTokens / contextLimit) * 100));
-    } else {
-      // Fallback to turn-count heuristic when prompt text unavailable
-      const maxTurns = 40;
-      remainingPercent = Math.max(0, Math.round((1 - session.turnCount / maxTurns) * 100));
     }
 
     // Determine bracket

package/framework/intelligence/context-engine.md

@@ -12,10 +12,10 @@ Four brackets define behavior based on remaining context:
 
 | Bracket | Context Remaining | Behavior |
 |---------|-------------------|----------|
-| **FRESH** | 60-100% | All 6 layers active. Minimal reinforcement (1.5%) — context is plentiful. No memory injection. |
-| **MODERATE** | 40-60% | 5 layers (skip L4). Growing reinforcement (2.5%) — model starting to forget. Metadata memory. |
-| **DEPLETED** | 25-40% | 3 layers (L0-L2). Heavy reinforcement (4.0%) — significant context loss. Chunk memory recovery. |
-| **CRITICAL** | <25% | 2 layers (L0-L1). Maximum reinforcement (5.0%) — last interactions before handoff. Full memory dump. |
+| **FRESH** | 60-100% | 2 layers (L0-L1). Minimal reinforcement (1.5%) — model has full memory, no need to re-inject. |
+| **MODERATE** | 40-60% | 4 layers (L0-L3). Growing reinforcement (2.5%) — model starting to forget. |
+| **DEPLETED** | 25-40% | All 6 layers (L0-L5). Heavy reinforcement (4.0%) — significant context loss, full re-injection. |
+| **CRITICAL** | <25% | All 6 layers (L0-L5). Maximum reinforcement (5.0%) — forced handoff, do not accept degraded output. |
 
 ### Static/Dynamic PRISM Boundary
 
@@ -38,18 +38,18 @@ The orchestrator injects context through 6 hierarchical layers:
 | **L2** | Agent Scope | `chati.dev/agents/{agent}/` — mission, inputs, outputs, criteria | When agent is active |
 | **L3** | Pipeline State | `.chati/session.yaml` — pipeline position, scores, backlog | When session is active |
 | **L4** | Task Context | Active artifact + previous agent's handoff | When task is active |
-| **L5** | Keywords | `chati.dev/domains/keywords/` — dynamic rules from user prompt | FRESH + MODERATE only |
+| **L5** | Keywords | `chati.dev/domains/keywords/` — dynamic rules from user prompt | DEPLETED + CRITICAL only |
 
 ### Layer Activation by Bracket
 
 | Bracket | Active Layers | Budget Ratio | Claude (200K) | Gemini (1M) | Codex (128K) |
 |---------|--------------|-------------|---------------|-------------|--------------|
-| FRESH | L0, L1, L2, L3, L4, L5 | 1.5% | 3,000 | 15,000 | 1,920 |
-| MODERATE | L0, L1, L2, L3, L5 | 2.5% | 5,000 | 25,000 | 3,200 |
-| DEPLETED | L0, L1, L2 | 4.0% | 8,000 | 40,000 | 5,120 |
-| CRITICAL | L0, L1 | 5.0% | 10,000 | 50,000 | 6,400 |
+| FRESH | L0, L1 | 1.5% | 3,000 | 15,000 | 1,920 |
+| MODERATE | L0, L1, L2, L3 | 2.5% | 5,000 | 25,000 | 3,200 |
+| DEPLETED | L0, L1, L2, L3, L4, L5 | 4.0% | 8,000 | 40,000 | 5,120 |
+| CRITICAL | L0, L1, L2, L3, L4, L5 | 5.0% | 10,000 | 50,000 | 6,400 |
 
-Budgets are proportional to the provider's context window. As context degrades, fewer layers are active (focus) but each active layer receives MORE reinforcement tokens (strength).
+Progressive Reinforcement: as context depletes, BOTH budget AND layers increase. The model forgets initial instructions and needs more reinforcement, not less.
 
 ---
 
@@ -182,7 +182,7 @@ Memory injection follows the same progressive reinforcement principle: as contex
 
 ## Constitution Reference
 
-**Article XII: Context Bracket Governance** — Brackets are calculated automatically. In CRITICAL, only L0+L1 are injected. Handoff is mandatory when context < 15%.
+**Article XII: Context Bracket Governance** — Brackets are calculated automatically. In CRITICAL, all 6 layers (L0-L5) are injected for maximum reinforcement. Handoff is mandatory when context < 15%.
 
 ---
 

package/framework/orchestrator/chati-update.md

@@ -0,0 +1,321 @@
+# /chati-update — Evolution Advisor with Self-Validated Implementation
+
+You are the **Chati Update Agent**, a specialized evolution advisor for the chati.dev framework. Your mission is to analyze an external repo/project, perform exhaustive cross-comparison with chati.dev's current state, propose improvements, and implement approved changes with ralph-wiggum self-validation at 95% threshold.
+
+**Input:** $ARGUMENTS (path to local repo OR GitHub URL)
+
+---
+
+## CRITICAL RULES
+
+1. **NEVER copy blindly** — Adapt concepts to chati.dev's identity and patterns
+2. **NEVER break existing tests** — All 989+ tests must continue passing
+3. **NEVER violate the constitution** — 19 articles are sacred
+4. **NEVER skip comparison** — Every finding MUST be validated against current state
+5. **ALWAYS present options** — Numbered 1, 2, 3 format before any implementation
+6. **ALWAYS use sub-agents** — Parallelize SCAN and COMPARE for throughput
+7. **ORIGINALITY 100%** — Zero copies, zero external framework references in code/docs
+
+---
+
+## Phase 0: PREPARE — Resolve Input
+
+```
+IF $ARGUMENTS is empty:
+  → Ask user: "Which repo do you want me to analyze? Provide a local path or GitHub URL."
+  → STOP and wait
+
+IF $ARGUMENTS is a GitHub URL (https://github.com/...):
+  → Clone to /tmp/chati-update-ref/ using: git clone --depth 1 <URL> /tmp/chati-update-ref
+  → Set REF_PATH = /tmp/chati-update-ref
+
+IF $ARGUMENTS is a local path:
+  → Verify path exists
+  → Set REF_PATH = $ARGUMENTS
+
+IF $ARGUMENTS is a GitHub shorthand (owner/repo):
+  → Clone to /tmp/chati-update-ref/ using: git clone --depth 1 https://github.com/$ARGUMENTS /tmp/chati-update-ref
+  → Set REF_PATH = /tmp/chati-update-ref
+```
+
+---
+
+## Phase 1: SCAN — Deep Analysis of Reference Repo (Sub-Agent)
+
+Launch a **Task agent (subagent_type=Explore, thoroughness=very thorough)** to analyze the reference repo at REF_PATH.
+
+### SCAN Agent Instructions:
+
+```
+Analyze the repo at <REF_PATH> exhaustively. You must produce a comprehensive report covering:
+
+1. **PROJECT OVERVIEW**
+   - What does this project do?
+   - Tech stack, language, framework
+   - Project maturity (commits, stars, contributors if visible)
+   - License
+
+2. **ARCHITECTURE PATTERNS**
+   - Folder structure and organization philosophy
+   - Module/plugin/agent system (if any)
+   - Configuration patterns (YAML, JSON, env)
+   - CLI patterns and entry points
+
+3. **INTERESTING CONCEPTS** (the gold — be thorough)
+   - Novel patterns not commonly seen
+   - Quality gates, validation systems
+   - Context management strategies
+   - Agent/AI orchestration patterns
+   - Pipeline/workflow patterns
+   - Memory/state management
+   - Error handling patterns
+   - Testing strategies
+   - Documentation patterns
+   - Hook/plugin systems
+   - CI/CD patterns
+
+4. **CODE QUALITY SIGNALS**
+   - Test coverage approach
+   - Linting/formatting standards
+   - Type safety patterns
+   - Security patterns
+
+5. **SPECIFIC ARTIFACTS** — For each interesting file/pattern:
+   - File path
+   - What it does
+   - Why it's interesting
+   - Key code snippets (actual content, not summaries)
+
+Be EXHAUSTIVE. Read every important file. Don't summarize — extract actual patterns with code.
+Minimum 30 files analyzed. No laziness.
+```
+
+---
+
+## Phase 2: COMPARE — Cross-Reference with Chati.dev (Sub-Agent)
+
+Launch **in parallel** with Phase 1 a **Task agent (subagent_type=Explore, thoroughness=very thorough)** to map chati.dev's current state.
+
+### COMPARE Baseline Agent Instructions:
+
+```
+Map the COMPLETE current state of chati.dev. Analyze:
+
+1. **CONSTITUTION** — Read chati.dev/constitution.md fully. Extract:
+   - All 19 articles with key rules
+   - Quality thresholds
+   - Governance patterns
+
+2. **ALL AGENTS** — Read every file in chati.dev/agents/**/*.md:
+   - Agent identity, role, pipeline position
+   - Input/output contracts
+   - Acceptance criteria
+   - Key patterns each agent uses
+
+3. **ORCHESTRATOR** — Read chati.dev/orchestrator/chati.md fully:
+   - Routing logic
+   - Session management
+   - Deviation handling
+
+4. **WORKFLOWS** — Read chati.dev/workflows/*.yaml:
+   - Workflow definitions
+   - Step sequences
+   - Gate conditions
+
+5. **SCHEMAS** — Read chati.dev/schemas/*.json:
+   - Session schema
+   - Handoff schema
+   - Config schema
+
+6. **HOOKS** — Read packages/chati-dev/src/**/*:
+   - All 6 hooks
+   - PRISM engine
+   - Mode governance
+   - Build loop / autonomy system
+
+7. **TESTS** — Map test structure:
+   - Test organization
+   - Coverage patterns
+   - Key test utilities
+
+8. **CONFIG** — Read chati.dev/config.yaml, package.json:
+   - Version info
+   - Dependencies
+   - Scripts
+
+Produce a COMPLETE inventory. Every file, every pattern, every decision.
+This is the baseline for comparison. Be thorough.
+```
+
+---
+
+## Phase 3: CROSS-ANALYZE — Merge Findings
+
+Once both sub-agents complete, YOU (main agent) perform the cross-analysis:
+
+### For EACH finding from the SCAN:
+
+```yaml
+finding: <name>
+source_repo: <file path in reference repo>
+category: architecture | quality | testing | docs | patterns | tooling | governance
+classification: ADOPT | ADAPT | IGNORE | ALREADY_EXISTS
+reasoning: <why this classification>
+chati_equivalent: <existing chati.dev file/pattern if any, or "none">
+impact: high | medium | low
+effort: high | medium | low
+priority_score: <impact * inverse_effort, 1-10>
+implementation_notes: <how to implement in chati.dev context>
+constitution_check: <which articles are relevant, any conflicts>
+```
+
+### Classification Rules:
+- **ADOPT**: Novel concept, no equivalent in chati.dev, high value, no conflicts
+- **ADAPT**: Similar concept exists but reference has better implementation
+- **IGNORE**: Not relevant, conflicts with constitution, or low value
+- **ALREADY_EXISTS**: Chati.dev already has this (possibly better)
+
+---
+
+## Phase 4: PROPOSE — Present to User
+
+Generate a structured report for the user:
+
+```markdown
+# Chati Update Report: <repo-name>
+
+## Summary
+- Findings analyzed: N
+- ADOPT: N items
+- ADAPT: N items
+- ALREADY_EXISTS: N items
+- IGNORE: N items
+
+## Recommendations (sorted by priority_score desc)
+
+### ADOPT — New Concepts Worth Adding
+
+1. **<Finding Name>** (Priority: X/10)
+   - **What**: <description>
+   - **Why**: <value to chati.dev>
+   - **Where**: <which chati.dev files would change>
+   - **Effort**: <high/medium/low>
+   - **Constitution**: <compatible with articles X, Y>
+
+2. ...
+
+### ADAPT — Existing Concepts Worth Improving
+
+1. **<Finding Name>** (Priority: X/10)
+   - **Current**: <how chati.dev does it today>
+   - **Improvement**: <what the reference does better>
+   - **Where**: <which files to modify>
+   - **Effort**: <high/medium/low>
+
+2. ...
+
+### ALREADY_EXISTS — Chati.dev Already Has This
+(brief list for transparency)
+
+### IGNORE — Not Applicable
+(brief list with reasons)
+```
+
+Then ask the user:
+> "Which items do you want me to implement? Give me the numbers (e.g., 'ADOPT 1, 3' and 'ADAPT 2') or say 'all ADOPT' / 'all'."
+
+---
+
+## Phase 5: APPLY + RALPH — Self-Validated Implementation
+
+For the approved changes, enter ralph-wiggum mode:
+
+### Pre-Ralph Checklist:
+1. Run current tests: `npm test` — record baseline (must be green)
+2. Run lint: `npm run lint` — record baseline
+3. Git status — ensure clean working directory
+4. Create branch: `git checkout -b chati-update/<repo-name>-<date>`
+
+### Ralph Loop Activation:
+
+Use `/ralph-loop` with the following prompt structure:
+
+```
+/ralph-loop "Implement the following approved chati-update changes:
+
+<LIST OF APPROVED CHANGES WITH FULL DETAILS>
+
+REQUIREMENTS:
+1. Implement each change following chati.dev patterns and conventions
+2. Respect the constitution (19 articles) — especially originality
+3. Update relevant tests for each change
+4. Run full test suite after each change — ALL must pass
+5. Run lint after each change — must be clean
+6. Validate against constitution rules
+7. Each change must score >= 95% on self-validation
+
+SELF-VALIDATION CHECKLIST (must ALL be true):
+- [ ] All existing tests pass (989+)
+- [ ] New tests added for new functionality
+- [ ] Lint passes with zero errors
+- [ ] No external framework references (originality 100%)
+- [ ] Constitution articles respected
+- [ ] No regressions in any agent definitions
+- [ ] Handoff format maintained
+- [ ] PRISM layers intact
+- [ ] Config/schemas updated if needed
+- [ ] CHANGELOG updated
+
+When ALL items are validated at >= 95%, output:
+<promise>ALL CHANGES VALIDATED AT 95%</promise>" --completion-promise "ALL CHANGES VALIDATED AT 95%" --max-iterations 15
+```
+
+---
+
+## Phase 6: REPORT — Final Summary
+
+After ralph-wiggum completes, generate final report:
+
+```markdown
+# Chati Update Complete
+
+## Changes Applied
+- <list of implemented changes with file paths>
+
+## Validation Results
+- Tests: X passing (was Y before)
+- Lint: clean
+- Constitution: no violations
+- Self-validation score: X%
+
+## Files Modified
+- <file list with brief description of changes>
+
+## Files Created
+- <if any>
+
+## Next Steps
+- <any follow-up recommendations>
+```
+
+---
+
+## Error Handling
+
+- **Clone fails**: Ask user for correct URL/path, suggest alternatives
+- **Tests fail at baseline**: STOP — do not proceed with changes on a broken baseline. Report to user.
+- **Ralph stuck (> 10 iterations without progress)**: Break loop, report what was achieved, ask user for guidance
+- **Constitution conflict detected**: STOP that specific change, report conflict, ask user for deviation approval
+- **Sub-agent returns incomplete data**: Re-run that specific sub-agent with more specific instructions
+
+---
+
+## Anti-Patterns (NEVER do these)
+
+- Don't copy code verbatim from reference repo
+- Don't rename chati.dev concepts to match reference repo naming
+- Don't add dependencies from reference repo without explicit approval
+- Don't modify the constitution
+- Don't skip the comparison phase ("it looks good, let's just add it")
+- Don't implement without user approval of the proposal
+- Don't rush — thoroughness > speed

package/framework/orchestrator/chati.md

@@ -94,51 +94,40 @@ CRITICAL → "Context: CRITICAL ({remaining}%) — Initiating handoff protocol"
 
 ## Action: Setup
 
-The user is starting a new project.
+The user is starting a new project. The orchestrator handles all setup decisions automatically — the user should NOT be asked to choose workflows, pipelines, or technical options. They just describe what they want to build.
 
-### Quick Flow Auto-Detection
+### Automatic Detection
 
-Before asking for workflow, check if this is a quick-flow candidate:
-```
-Run: node packages/chati-dev/bin/chati.js orchestrate detect-flow --message "{user_first_message}"
-```
-
-If `recommended` is `quick` (confidence >= 0.8):
-  → Present: "This looks like a quick task. I can use Quick Flow (fast-track):
-     Brief (quick) → Dev → QA → Deploy
-     1. Use Quick Flow (Recommended)
-     2. Use full pipeline instead"
-
-If `recommended` is `standard`:
-  → Present: "This looks like a medium feature. Standard Flow recommended:
-     Brief → Detail → Architect → Tasks → QA-Planning → Dev → QA → Deploy
-     1. Use Standard Flow (Recommended)
-     2. Use full pipeline instead"
-
-### Project Setup
-
-1. **Project type**: Does an existing codebase exist?
+1. **Project type**: Detect automatically.
    - Check for `package.json`, `src/`, `.git`, etc.
    - If exists → `brownfield`. If not → `greenfield`.
-   - If ambiguous, ask: "Is this a new project or an existing one?"
+   - Only ask if truly ambiguous (no signals at all).
 
 2. **Language**: Detect from user's message language.
    - Supported: `en`, `pt`, `es`, `fr`. Default: `en`.
 
-3. **Workflow**: Use auto-detected or ask user:
+3. **Workflow**: Decide automatically based on context. NEVER present workflow options to the user.
    ```
-   1. Full Pipeline (Recommended for new features, greenfield)
-   2. Quick Flow (Bug fixes, small changes, hotfixes)
-   3. Standard Flow (Medium features, no UX/architecture needed)
+   Run: node packages/chati-dev/bin/chati.js orchestrate detect-flow --message "{user_first_message}"
    ```
+   Use the `recommended` field directly:
+   - `quick` (confidence >= 0.8) → workflow = `quick`
+   - `standard` (confidence >= 0.8) → workflow = `standard`
+   - Otherwise → workflow = `full`
+
+4. **Project name**: Extract from user's message or directory name. Only ask if undetectable.
+
+### Initialize
 
-Then run via Bash:
+Run via Bash:
 ```
-node packages/chati-dev/bin/chati.js orchestrate init --type greenfield --language pt --name "project-name" --workflow full
+node packages/chati-dev/bin/chati.js orchestrate init --type {detected_type} --language {detected_lang} --name "{detected_name}" --workflow {detected_workflow}
 ```
 
 Parse JSON → read `first_agent_file` → activate that agent immediately (go to **Action: Interactive Agent**).
 
+The user should experience a smooth start: they describe their project, the orchestrator confirms what it detected, and the first agent begins immediately.
+
 ---
 
 ## Action: Interactive Agent
@@ -154,11 +143,61 @@ These agents (greenfield-wu, brownfield-wu, brief) run in the same conversation.
 3. Load its full content and **become** that agent
 4. Follow the agent's instructions — the user interacts with you directly
 5. When the agent completes its work and self-validates, extract the score
-6. Run via Bash:
+6. Present **Completion Options** (see below) — wait for user choice before advancing
+7. On user approval, run via Bash:
    ```
    node packages/chati-dev/bin/chati.js orchestrate advance --agent {name} --score {score}
    ```
-7. Parse JSON → the `next` field contains the next action → follow it
+8. Parse JSON → the `next` field contains the next action → follow it
+
+---
+
+## Completion Options (Protocol 3 — Guided Options)
+
+After EVERY agent completes (interactive or autonomous), present exactly 3 numbered options. The user should never have to figure out "what now" — always offer clear next steps with a recommendation.
+
+### Standard Completion (score >= threshold)
+```
+{agent} completed with score {score}%.
+
+1. Approve and continue to {next_agent} (Recommended)
+2. Review the artifacts before proceeding
+3. Revise — go back and adjust specific points
+```
+
+### Low Score Completion (score < threshold but not blocking)
+```
+{agent} completed with score {score}% (below {threshold}% threshold).
+
+1. Revise — re-run {agent} to improve quality (Recommended)
+2. Approve anyway and continue to {next_agent}
+3. Review the artifacts and decide
+```
+
+### Parallel Group Completion
+```
+Parallel group completed: {agents with scores}.
+
+1. Approve all and continue to {next_agent} (Recommended)
+2. Review artifacts from a specific agent
+3. Re-run a specific agent for improvements
+```
+
+### Pipeline Milestone (after QA-Planning or QA-Implementation)
+```
+Quality gate passed: {score}%.
+
+1. Approve and advance to {next_phase} (Recommended)
+2. View detailed QA report
+3. Request additional review on specific areas
+```
+
+**Rules:**
+- ALWAYS present options — never leave the user without a clear next step
+- ALWAYS mark one option as "(Recommended)"
+- User can respond with just the number (1, 2, or 3)
+- If user responds with free text instead of a number, interpret their intent and act accordingly
+- Keep options in the user's language
 
 ---
 
@@ -179,7 +218,7 @@ These agents run in separate Claude Code processes.
    - If `true`: display "Context check: OK — handoff verified"
 3. Execute `spawn_command` via Bash tool (the full command is in the JSON)
 4. Wait for JSON output from the spawned process. Handle `status`:
-   - `"complete"` → Run `orchestrate advance --agent {name} --score {score}`
+   - `"complete"` → Present **Completion Options** (see above) → on approval, run `orchestrate advance --agent {name} --score {score}`
    - `"needs_input"` → Read `needs_input_question`, present to user in their language, then re-run spawn with `--additional-context "{user_response}"` (max 3 relay cycles)
    - `"error"` → Apply Recovery Protocol (see below)
 
@@ -201,8 +240,9 @@ Planning phase agents (detail, architect, ux) run simultaneously.
 1. Display: "Spawning parallel group: {agents}"
 2. Execute `parallel_spawn_command` via Bash tool
 3. Parse consolidated JSON output
-4. For each completed agent, run `orchestrate advance --agent {name} --score {score}`
-5. If partial failure:
+4. Present **Completion Options** (Parallel Group variant) — wait for user choice
+5. On approval, for each completed agent, run `orchestrate advance --agent {name} --score {score}`
+6. If partial failure:
    ```
    1. Retry failed agents only
    2. Continue with partial results
@@ -389,6 +429,8 @@ interactive (default):
   → All 8 universal protocols apply.
 
 autonomous (Ralph Wiggum mode):
+  → Requires: most recent QA gate score >= 95% (Article XVIII prerequisite).
+  → If quality gate not met, inform user and suggest guided mode instead.
   → Agent executes without asking unless blocker encountered.
   → Primarily for Dev agent during BUILD phase.
   → QA gates always run regardless of mode.

package/framework/schemas/context.schema.json

@@ -19,7 +19,7 @@
     },
     "agent": {
       "type": "object",
-      "description": "Active agent scope information (L2 layer, active when bracket >= DEPLETED)",
+      "description": "Active agent scope information (L2 layer, active when bracket >= MODERATE)",
       "required": ["name", "mission"],
       "properties": {
         "name": { "type": "string", "description": "Agent identifier" },
@@ -32,14 +32,15 @@
     "pipeline": {
       "type": "string",
       "description": "Pipeline state string showing agent progression (L3 layer, active when bracket >= MODERATE)"
+
     },
     "task": {
       "type": "string",
-      "description": "Current task description (L4 layer, active when bracket >= MODERATE)"
+      "description": "Current task description (L4 layer, active when bracket = DEPLETED or CRITICAL)"
     },
     "handoff": {
       "type": "object",
-      "description": "Previous agent handoff summary (L4 layer, active when bracket >= MODERATE)",
+      "description": "Previous agent handoff summary (L4 layer, active when bracket = DEPLETED or CRITICAL)",
       "properties": {
         "from": { "type": "string", "description": "Source agent name" },
         "score": { "type": "number", "minimum": 0, "maximum": 100, "description": "Source agent final score" },
@@ -83,7 +84,7 @@
         "injection_budget": {
           "type": "integer",
           "minimum": 0,
-          "description": "Token budget for context injection (FRESH: 2500, MODERATE: 2000, DEPLETED: 1500, CRITICAL: 800)"
+          "description": "Token budget for context injection — Progressive Reinforcement: FRESH 1.5%, MODERATE 2.5%, DEPLETED 4.0%, CRITICAL 5.0% of provider context window"
         }
       }
     },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chati-dev",
-  "version": "4.1.1",
+  "version": "4.1.3",
   "description": "AI-Powered Multi-Agent Orchestration System — Structured vibe coding for Full Stack Development",
   "type": "module",
   "bin": {

package/src/context/bracket-tracker.js

@@ -1,21 +1,20 @@
 /**
  * Bracket Tracker — Pure arithmetic for context window management.
  *
- * Brackets determine how much context to inject:
- *   FRESH    (60-100%) → All 6 layers active (L0-L5)
- *   MODERATE (40-60%)  → L0 + L1 + L2 + L3 + L5 (skip L4 task detail)
- *   DEPLETED (25-40%)  → L0 + L1 + L2 only
- *   CRITICAL (<25%)    → L0 + L1 only (handoff mandatory)
+ * Brackets determine how much context to inject (Progressive Reinforcement):
+ *   FRESH    (60-100%) → L0 + L1 only (model has full memory, minimal reinforcement)
+ *   MODERATE (40-60%)  → L0 + L1 + L2 + L3 (model starting to forget)
+ *   DEPLETED (25-40%)  → All 6 layers L0-L5 (significant context loss, full reinforcement)
+ *   CRITICAL (<25%)    → All 6 layers L0-L5 + handoff mandatory (maximum reinforcement)
  *
- * Progressive Reinforcement Model (v4.0):
- *   As context window depletes, the model forgets initial instructions
- *   and needs MORE reinforcement, not less. Budget expressed as percentage
- *   of the provider's total context window — proportional across providers.
+ * Progressive Reinforcement Model (v4.1.2):
+ *   As context depletes, BOTH budget AND layers INCREASE.
+ *   The model forgets initial instructions and needs MORE reinforcement.
  *
- *   FRESH    = 1.5% → minimal reinforcement (context is plentiful)
- *   MODERATE = 2.5% → growing reinforcement (model starting to forget)
- *   DEPLETED = 4.0% → heavy reinforcement (significant context loss)
- *   CRITICAL = 5.0% → maximum reinforcement (last interactions before handoff)
+ *   FRESH    = 1.5% budget, 2 layers → context intact, no need to re-inject
+ *   MODERATE = 2.5% budget, 4 layers → growing reinforcement
+ *   DEPLETED = 4.0% budget, 6 layers → full layer injection to compensate loss
+ *   CRITICAL = 5.0% budget, 6 layers → maximum reinforcement + forced handoff
  */
 
 import { resolveContextLimit } from '../utils/provider-limits.js';

package/src/context/formatter.js

@@ -54,8 +54,9 @@ export function formatContext(options) {
 
   // Insert STATIC_BOUNDARY between static (L0+L1) and dynamic (L2-L5) sections.
   // This enables prompt cache reuse for the stable prefix (Claude Code pattern).
-  const staticSections = sections.slice(0, l1 ? 2 : (l0 ? 1 : 0));
-  const dynamicSections = sections.slice(staticSections.length);
+  const staticCount = l1 ? 2 : (l0 ? 1 : 0);
+  const staticSections = sections.slice(0, staticCount);
+  const dynamicSections = sections.slice(staticCount);
 
   let body;
   if (dynamicSections.length > 0) {
@@ -69,7 +70,7 @@ export function formatContext(options) {
   // Truncate if over budget (rough estimate: 1 token ≈ 4 chars)
   const maxChars = tokenBudget * 4;
   if (body.length > maxChars) {
-    body = truncateByPriority(sections, maxChars);
+    body = truncateByPriority(sections, maxChars, staticCount);
   }
 
   return `<chati-context bracket="${bracket}">\n${body}\n</chati-context>`;
@@ -190,14 +191,28 @@ function formatKeywords(l5) {
  * Truncate sections by removing lower-priority layers first (L4 → L3 → L2).
  * L0 and L1 are never truncated.
  */
-function truncateByPriority(sections, maxChars) {
-  let result = sections.join('\n\n');
-  // Remove from end (lowest priority) until within budget
+function truncateByPriority(sections, maxChars, staticCount = 2) {
+  const boundaryMarker = '\n\n  <!-- STATIC_BOUNDARY -->\n\n';
   const trimmed = [...sections];
-  while (trimmed.length > 2 && result.length > maxChars) {
+  const hasDynamic = () => trimmed.length > staticCount;
+  const overhead = hasDynamic() ? boundaryMarker.length : 0;
+  const adjustedMax = maxChars - overhead;
+
+  // Remove from end (lowest priority) until within budget
+  while (trimmed.length > staticCount && trimmed.join('\n\n').length > adjustedMax) {
     trimmed.pop();
+  }
+
+  // Re-insert boundary if we still have both static and dynamic sections
+  let result;
+  if (hasDynamic()) {
+    result = trimmed.slice(0, staticCount).join('\n\n') +
+      boundaryMarker +
+      trimmed.slice(staticCount).join('\n\n');
+  } else {
     result = trimmed.join('\n\n');
   }
+
   // If still over, hard truncate
   if (result.length > maxChars) {
     result = result.slice(0, maxChars) + '\n  <!-- truncated -->';

package/src/context/layers/l5-keywords.js

@@ -6,7 +6,7 @@
  *   L0-L4 handle WHO (agent) and WHERE (workflow/task)
  *   L5 handles WHAT (topic detection from user prompt)
  *
- * Only active in FRESH and MODERATE brackets (expensive layer).
+ * Only active in DEPLETED and CRITICAL brackets (reinforcement layer).
  */
 
 import { loadKeywordDomains } from '../domain-loader.js';

package/src/memory/dream.js

@@ -45,6 +45,14 @@ export function runDreamConsolidation(projectDir) {
   // Phase 4: Prune
   report.phase4 = prune(projectDir, report.phase3.consolidated);
 
+  // Write consolidated memories to disk
+  try {
+    const sharedDir = join(projectDir, '.chati', 'memories', 'shared');
+    mkdirSync(sharedDir, { recursive: true });
+    const consolidatedPath = join(sharedDir, 'consolidated.json');
+    writeFileSync(consolidatedPath, JSON.stringify(report.phase4.entries, null, 2), 'utf-8');
+  } catch (err) { process.stderr.write(`[chati] dream write consolidated: ${err.message}\n`); }
+
   // Summary
   report.summary = {
     merged: report.phase3.mergedCount,
@@ -198,6 +206,7 @@ function prune(projectDir, consolidated) {
       prunedCount: 0,
       archivedCount: 0,
       remaining: consolidated.length,
+      entries: consolidated,
     };
   }
 
@@ -238,6 +247,7 @@ function prune(projectDir, consolidated) {
     prunedCount: toRemove.length,
     archivedCount,
     remaining: toKeep.length,
+    entries: toKeep,
   };
 }
 

package/src/memory/memory-extractor.js

@@ -115,7 +115,7 @@ export function extractMemories(text, context = {}) {
   // Build memory entries following memory.schema.json
   const now = new Date().toISOString();
   return selected.map((candidate, i) => ({
-    id: `mem-${now.split('T')[0]}-${String(i + 1).padStart(3, '0')}`,
+    id: `mem-${now.replace(/[:.]/g, '-')}-${String(i + 1).padStart(3, '0')}`,
     type: candidate.type,
     agent: context.agent || 'unknown',
     content: candidate.content,

package/src/orchestrator/cli.js

@@ -178,7 +178,8 @@ function resolveAgentModel(agent, projectDir) {
     if (existsSync(configPath)) {
       const configRaw = readFileSync(configPath, 'utf-8');
       // Simple YAML parsing for agent_overrides section
-      const overrideMatch = configRaw.match(new RegExp(`${agent}:\\s*\\n\\s+provider:\\s*(\\w+)`, 'm'));
+      const escapedAgent = agent.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+      const overrideMatch = configRaw.match(new RegExp(`${escapedAgent}:\\s*\\n\\s+provider:\\s*(\\w+)`, 'm'));
       if (overrideMatch) {
         return { ...defaults, provider: overrideMatch[1] };
       }

package/src/scanning/leakage-scanner.js

@@ -13,7 +13,9 @@ const TECH_NAMES = [
   /\bExpress\b/g, /\bFastify\b/g, /\bDjango\b/g, /\bFlask\b/g, /\bLaravel\b/g,
   /\bAWS\b/g, /\bVercel\b/g, /\bNetlify\b/g, /\bRailway\b/g, /\bCloudflare\b/g,
   /\bDocker\b/g, /\bKubernetes\b/g, /\bRedis\b/g, /\bGraphQL\b/gi,
-  /\bTypeScript\b/gi, /\bJavaScript\b/gi, /\bPython\b/g, /\bRust\b/g, /\bGo\b/g,
+  /\bTypeScript\b/gi, /\bJavaScript\b/gi, /\bPython\b/g,
+  /\bRustlang\b|\bRust\s+(?:lang|crate|cargo|tokio|async|compiler)\b/gi,
+  /\bGolang\b|\bGo\s+(?:module|package|routine|channel|func|goroutine)\b/g,
   /\bZod\b/g, /\bJoi\b/g, /\bZustand\b/g, /\bRedux\b/g, /\bJotai\b/g,
 ];
 

package/src/security/bash-security.js

@@ -62,9 +62,9 @@ export const SECURITY_CHECKS = [
   {
     id: 'SHELL_METACHARACTERS',
     name: 'Shell metacharacter injection',
-    pattern: /[`]|(?:\$\((?!.*\becho\b))/,
+    pattern: /[`]|\$\(/,
     severity: 'critical',
-    description: 'Backticks or $() command substitution (excluding safe echo patterns)',
+    description: 'Backticks or $() command substitution',
   },
   {
     id: 'DANGEROUS_VARIABLES',

package/src/utils/brackets.js

@@ -4,8 +4,10 @@
  * Single source of truth for bracket thresholds, layer configurations,
  * and budget ratios. Consumers import from here to avoid duplication.
  *
- * Progressive Reinforcement Model (v4.0):
- *   As context depletes, budget INCREASES (model needs MORE reinforcement).
+ * Progressive Reinforcement Model (v4.1.2):
+ *   As context depletes, both budget AND layers INCREASE.
+ *   FRESH = model has full memory, minimal reinforcement needed.
+ *   CRITICAL = model forgot initial instructions, maximum reinforcement + handoff.
  *   Budget expressed as ratio of provider's total context window.
  */
 
@@ -14,10 +16,10 @@
  * @type {Record<string, {min: number, max: number, layers: string[], budgetRatio: number}>}
  */
 export const BRACKETS = {
-  FRESH:    { min: 60, max: 100, layers: ['L0', 'L1', 'L2', 'L3', 'L4', 'L5'], budgetRatio: 0.015 },
-  MODERATE: { min: 40, max: 60,  layers: ['L0', 'L1', 'L2', 'L3', 'L5'],       budgetRatio: 0.025 },
-  DEPLETED: { min: 25, max: 40,  layers: ['L0', 'L1', 'L2'],                   budgetRatio: 0.040 },
-  CRITICAL: { min: 0,  max: 25,  layers: ['L0', 'L1'],                         budgetRatio: 0.050 },
+  FRESH:    { min: 60, max: 100, layers: ['L0', 'L1'],                         budgetRatio: 0.015 },
+  MODERATE: { min: 40, max: 60,  layers: ['L0', 'L1', 'L2', 'L3'],             budgetRatio: 0.025 },
+  DEPLETED: { min: 25, max: 40,  layers: ['L0', 'L1', 'L2', 'L3', 'L4', 'L5'], budgetRatio: 0.040 },
+  CRITICAL: { min: 0,  max: 25,  layers: ['L0', 'L1', 'L2', 'L3', 'L4', 'L5'], budgetRatio: 0.050 },
 };
 
 /**