oh-my-customcode 0.58.5 → 0.59.0

package/dist/cli/index.js

@@ -9325,7 +9325,7 @@ var init_package = __esm(() => {
     workspaces: [
       "packages/*"
     ],
-    version: "0.58.5",
+    version: "0.59.0",
     description: "Batteries-included agent harness for Claude Code",
     type: "module",
     bin: {

package/dist/index.js

@@ -1672,7 +1672,7 @@ var package_default = {
   workspaces: [
     "packages/*"
   ],
-  version: "0.58.5",
+  version: "0.59.0",
   description: "Batteries-included agent harness for Claude Code",
   type: "module",
   bin: {

package/package.json

@@ -3,7 +3,7 @@
   "workspaces": [
     "packages/*"
   ],
-  "version": "0.58.5",
+  "version": "0.59.0",
   "description": "Batteries-included agent harness for Claude Code",
   "type": "module",
   "bin": {

package/templates/.claude/hooks/hooks.json

@@ -165,7 +165,7 @@
         "hooks": [
           {
             "type": "prompt",
-            "prompt": "Context compacted. RULES STILL ACTIVE — no exceptions.\n\nR007 FORMAT — Your NEXT response MUST start with:\n┌─ Agent: claude (default)\n└─ Task: {current task}\n\nR008 FORMAT — Before EVERY tool call:\n[claude][opus] → Tool: ToolName\n[claude][opus] → Target: /path/to/file\n\nR010 — ALL file writes MUST be delegated to subagents. Orchestrator uses Read/Glob/Grep ONLY. ALL git operations go through mgr-gitnerd.\n\nR009 — 2+ independent tasks → spawn agents in parallel, same message.\n\nR018 — 3+ agents OR review cycle → use Agent Teams.\n\nIf /tmp/.claude-autonomous-$PPID exists: R010 lightweight mode is active — simple git (add/commit/push) may execute directly, but file Write/Edit still requires delegation.\n\nPERMISSION MODE — bypassPermissions does not persist across context compaction. If the user previously enabled it and tasks seem blocked, inform them it may need re-enabling.\n\nRe-read CLAUDE.md NOW to restore project context."
+            "prompt": "Context compacted. RULES ACTIVE.\n\nR007: next response MUST start with ┌─ Agent: claude (default) / └─ Task: {task}\nR008: before EVERY tool call → [claude][model] → Tool: Name / Target: path\nR010: write→delegate to subagent; orchestrator read-only (Read/Glob/Grep); git→mgr-gitnerd\nR009: 2+ independent tasks → parallel agents, same message\nR018: 3+ agents OR review cycle → Agent Teams\n\nAutonomous mode: if /tmp/.claude-autonomous-$PPID exists → simple git (add/commit/push) may run directly; Write/Edit still delegates.\nbypassPermissions does NOT persist across compaction — re-enable if tasks seem blocked.\n\nRe-read CLAUDE.md NOW."
           }
         ],
         "description": "Reinforce enforced rules after context compaction — prevents rule amnesia (v2.1.76+)"

package/templates/.claude/rules/MAY-optimization.md

@@ -28,14 +28,15 @@
 
 Readability > Optimization. No optimization without measurement.
 
-## CLAUDE.md Context Optimization (v2.1.72+)
+## Context Optimization via HTML Comments (v2.1.72+)
 
-HTML comments in CLAUDE.md are hidden from the model during auto-injection but visible via Read tool.
+HTML comments in all auto-injected .md files (CLAUDE.md and rules/*.md) are hidden from the model during auto-injection but visible via Read tool.
 
 | Use Case | Example |
 |----------|---------|
-| Metadata tags | `<!-- agents: 44, skills: 74 -->` |
-| Validation checksums | `<!-- validate-docs: hash=abc123 -->` |
-| Conditional context | `<!-- detailed-architecture: see guides/architecture/ -->` |
+| Metadata tags | `<!-- agents: 44, skills: 74 -->` in CLAUDE.md |
+| Validation checksums | `<!-- validate-docs: hash=abc123 -->` in CLAUDE.md |
+| Conditional context | `<!-- detailed-architecture: see guides/architecture/ -->` in CLAUDE.md |
+| Rule detail hiding | `<!-- DETAIL: Self-Check ... -->` in rules/*.md |
 
 **Rule**: Move model-unnecessary metadata into HTML comments to reduce context token usage. Keep actionable instructions as visible text.

package/templates/.claude/rules/MUST-agent-design.md

@@ -50,6 +50,7 @@ domain: backend              # backend | frontend | data-engineering | devops |
 
 > **Note**: `isolation`, `background`, `maxTurns`, `maxTokens`, `mcpServers`, `hooks`, `permissionMode`, `disallowedTools`, `limitations` are supported in Claude Code v2.1.63+. Hook types `PostCompact`, `Elicitation`, `ElicitationResult` require v2.1.76+.
 
+<!-- DETAIL: Isolation/Token/Limitations/Escalation details
 ### Isolation Modes
 
 | Mode | Behavior | Use Case |
@@ -79,6 +80,7 @@ When `escalation.enabled: true`, the model-escalation hooks will track outcomes
 | `enabled` | false | Enable escalation tracking for this agent |
 | `path` | haiku → sonnet → opus | Model upgrade sequence |
 | `threshold` | 2 | Failure count before escalation advisory |
+-->
 
 ## Memory Scopes
 
@@ -92,51 +94,26 @@ When enabled: first 200 lines of MEMORY.md loaded into system prompt.
 
 ## Soul Identity
 
-Optional per-agent identity layer that separates personality/style from capabilities.
+Optional per-agent identity layer. `soul: true` in frontmatter enables personality/style via `.claude/agents/souls/{name}.soul.md`. Behavioral memory (R011) overrides soul defaults.
 
+<!-- DETAIL: Soul Identity full spec
 | Aspect | Location | Purpose |
 |--------|----------|---------|
 | Capabilities | `.claude/agents/{name}.md` | WHAT the agent does |
 | Identity | `.claude/agents/souls/{name}.soul.md` | HOW the agent communicates |
 
-### Soul File Format
-
-Location: `.claude/agents/souls/{name}.soul.md`
-
-```yaml
----
-agent: {agent-name}        # Must match agent filename
-version: 1.0.0
----
-```
-
-Sections: `## Personality`, `## Style`, `## Anti-patterns`
-
-### Activation
-
-1. Agent frontmatter includes `soul: true`
-2. Routing skill reads `souls/{name}.soul.md` at spawn time (Step 5)
-3. Soul content prepended to agent prompt as identity context
-4. Missing soul file → graceful fallback (no error)
-
-### Precedence
-
-Behavioral memory observations (R011) override soul defaults when they conflict. Behaviors are user-specific; souls are template defaults.
+### Soul File Format: agent: {name}, version: 1.0.0 — Sections: Personality, Style, Anti-patterns
+### Activation: frontmatter soul:true → routing skill reads souls/{name}.soul.md at spawn (Step 5) → prepend to prompt → missing file = graceful fallback
+-->
 
 ## Artifact Output Convention
 
-Skills that produce significant output can persist results to local storage.
-
-**Location**: `.claude/outputs/sessions/{YYYY-MM-DD}/{skill-name}-{HHmmss}.md`
+Skills persist output to `.claude/outputs/sessions/{YYYY-MM-DD}/{skill-name}-{HHmmss}.md`. Opt-in, git-untracked. Final subagent writes (R010).
 
+<!-- DETAIL: Artifact Output full spec
 **Format**: Metadata header with `skill`, `date`, `query` fields, followed by skill output content.
-
-**Rules**:
-- Opt-in per skill — not mandatory
-- The final subagent in the skill's pipeline writes the artifact (R010 compliance)
-- Skills create the directory (`mkdir -p`) before writing
-- `.claude/outputs/` is git-untracked (under `.claude/` gitignore)
-- No indexing required — date-based directory browsing is sufficient
+**Rules**: Opt-in per skill, final subagent writes (R010 compliance), Skills create directory (mkdir -p), .claude/outputs/ is git-untracked, no indexing required.
+-->
 
 ## Separation of Concerns
 
@@ -172,18 +149,11 @@ effort: medium              # low | medium | high — overrides model effort lev
 
 When both an agent and its invoked skill specify `effort`, the skill's value takes precedence (more specific invocation-time setting).
 
-### Skill Effectiveness Tracking
-
+<!-- DETAIL: Skill Effectiveness Tracking
 Skills can optionally track effectiveness metrics via auto-populated fields:
-
-```yaml
-effectiveness:              # Auto-populated by sys-memory-keeper
-  invocations: 0            # Total invocation count across sessions
-  success_rate: 0.0         # Success rate (0.0-1.0)
-  last_invoked: ""          # ISO-8601 timestamp
-```
-
-These fields are read-only from the skill's perspective — sys-memory-keeper updates them at session end based on task-outcome-recorder data. They inform model selection, routing optimization, and skill maintenance priorities.
+  effectiveness.invocations, effectiveness.success_rate (0.0-1.0), effectiveness.last_invoked (ISO-8601)
+Read-only from skill perspective — sys-memory-keeper updates at session end via task-outcome-recorder data.
+-->
 
 ## Skill Scope
 
@@ -197,19 +167,12 @@ Default: `core` (when field is omitted)
 
 ### Context Fork Criteria
 
-Use `context: fork` for skills that orchestrate multi-agent workflows. Cap at **12 total** across the project.
-
-| Use `context: fork` | Do NOT use `context: fork` |
-|---------------------|---------------------------|
-| Routing skills (secretary, dev-lead, etc.) | Best-practices skills |
-| Workflow orchestration (DAG, pipelines) | Hook/command skills |
-| Multi-agent coordination patterns | Single-agent reference skills |
-| Task decomposition/planning | External tool integrations |
+Use `context: fork` for multi-agent orchestration skills only. Cap: **12 total**. Current: 9/12 (secretary/dev-lead/de-lead/qa-lead-routing, dag-orchestration, task-decomposition, worker-reviewer-pipeline, pipeline-guards, deep-plan).
 
-Current skills with `context: fork` (9/12 cap):
-- secretary-routing, dev-lead-routing, de-lead-routing, qa-lead-routing
-- dag-orchestration, task-decomposition, worker-reviewer-pipeline, pipeline-guards
-- deep-plan
+<!-- DETAIL: Context Fork decision table
+| Use context:fork | Do NOT use context:fork |
+| Routing skills, Workflow orchestration (DAG), Multi-agent coordination, Task decomposition | Best-practices skills, Hook/command skills, Single-agent reference, External tool integrations |
+-->
 
 ## Naming
 

package/templates/.claude/rules/MUST-agent-teams.md

@@ -28,8 +28,9 @@ Available when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` or TeamCreate/SendMessag
 ## Self-Check (Before Agent Tool)
 
 Before using Agent tool for 2+ agent tasks, complete this check:
+Quick rule: 3+ agents OR review cycle → use Agent Teams. Sequential deps / scaffolding → Agent Tool. 2+ issues in same batch → prefer Agent Teams.
 
-```
+<!-- DETAIL: Self-Check (Before Agent Tool)
 ╔══════════════════════════════════════════════════════════════════╗
 ║  BEFORE USING Agent TOOL FOR 2+ AGENTS:                          ║
 ║                                                                   ║
@@ -58,15 +59,13 @@ Before using Agent tool for 2+ agent tasks, complete this check:
 ║  2+ issues in same batch → prefer Agent Teams                    ║
 ║  Everything else → Agent tool                                    ║
 ╚══════════════════════════════════════════════════════════════════╝
-```
+-->
 
 ### Spawn Completeness Check
 
-When spawning Agent Teams members:
-
 All members must be spawned in a single message. Partial spawning needs correction per R018 and R009.
 
-```
+<!-- DETAIL: Self-Check (Spawn Completeness)
 ╔══════════════════════════════════════════════════════════════════╗
 ║  BEFORE SPAWNING TEAM MEMBERS:                                   ║
 ║                                                                   ║
@@ -79,10 +78,9 @@ All members must be spawned in a single message. Partial spawning needs correcti
 ║  Sequential spawn (one per message) = needs correction           ║
 ║  All at once in single message = correct                         ║
 ╚══════════════════════════════════════════════════════════════════╝
-```
-
-### External Skill Conflict Resolution
+-->
 
+<!-- DETAIL: External Skill Conflict Resolution
 When an external skill instructs using Agent tool but R018 criteria are met:
 
 | Skill says | R018 requires | Resolution |
@@ -91,12 +89,23 @@ When an external skill instructs using Agent tool but R018 criteria are met:
 | "Sequential agent spawning" | Independent tasks → parallel | Parallelize per R009 |
 | "Skip coordination" | Shared state → Teams | Use Teams for coordination |
 
-**Rule**: External skills define the WORKFLOW. R018 defines the EXECUTION METHOD.
+Rule: External skills define the WORKFLOW. R018 defines the EXECUTION METHOD.
 The skill's steps are followed, but agent spawning uses Teams when criteria are met.
+-->
 
 ## Common Violations
 
 ```
+❌ WRONG: 3+ tasks using Agent tool instead of Agent Teams
+   Agent(Explore):haiku → Analysis 1
+   Agent(Explore):haiku → Analysis 2
+   Agent(Explore):haiku → Analysis 3
+
+✓ CORRECT: TeamCreate → spawn researchers → coordinate via shared task list
+   TeamCreate("research-team") + Agent(researcher-1/2/3) + SendMessage(coordinate)
+```
+
+<!-- DETAIL: Common Violations (full examples)
 ❌ WRONG: Agent Teams enabled, 3+ research tasks using Agent tool
    Agent(Explore):haiku → Analysis 1
    Agent(Explore):haiku → Analysis 2
@@ -141,7 +150,7 @@ The skill's steps are followed, but agent spawning uses Teams when criteria are
 
 ✓ CORRECT: Completed member reports and waits
    svelte-projects completes task → SendMessage("Task complete") → waits silently
-```
+-->
 
 ## Cost Guidelines
 
@@ -155,34 +164,30 @@ The skill's steps are followed, but agent spawning uses Teams when criteria are
 
 ## Team Patterns
 
-### Standard Patterns
+Standard: Research (researcher-1 + researcher-2 + synthesizer), Development (implementer + reviewer + tester), Debug (investigator-1 + investigator-2 + fixer).
+Hybrid: Review+Fix, Create+Validate, Multi-Expert, Dynamic Creation, Codex Hybrid.
 
-- **Research**: researcher-1 + researcher-2 + synthesizer
-- **Development**: implementer + reviewer + tester
-- **Debug**: investigator-1 + investigator-2 + fixer
+<!-- DETAIL: Team Patterns
+### Standard Patterns
+- Research: researcher-1 + researcher-2 + synthesizer
+- Development: implementer + reviewer + tester
+- Debug: investigator-1 + investigator-2 + fixer
 
 ### Hybrid Patterns
-
-- **Review+Fix**: reviewer + implementer (reviewer finds issues → implementer fixes → reviewer re-checks)
-- **Create+Validate**: mgr-creator + qa-engineer (create agent → validate → iterate)
-- **Multi-Expert**: expert-1 + expert-2 + coordinator (cross-domain tasks requiring multiple specialties)
+- Review+Fix: reviewer + implementer (reviewer finds issues → implementer fixes → reviewer re-checks)
+- Create+Validate: mgr-creator + qa-engineer (create agent → validate → iterate)
+- Multi-Expert: expert-1 + expert-2 + coordinator (cross-domain tasks requiring multiple specialties)
 
 ### Dynamic Patterns
+- Dynamic Creation: mgr-creator + domain-expert (create new agent → immediately use for pending task)
+- Codex Hybrid: codex-exec-agent + claude-reviewer (Codex generates → Claude reviews/refines)
 
-- **Dynamic Creation**: mgr-creator + domain-expert (create new agent → immediately use for pending task)
-- **Codex Hybrid**: codex-exec-agent + claude-reviewer (Codex generates → Claude reviews/refines)
-
-## Codex-Exec Integration
-
+### Codex-Exec Integration
 When both Agent Teams and codex-exec are available:
-
-```
-Hybrid Workflow:
   1. Claude agent analyzes requirements
   2. codex-exec generates implementation (Codex strength: code generation)
   3. Claude agent reviews and refines (Claude strength: reasoning, quality)
   4. Iterate via team messaging until quality meets standards
-```
 
 | Step | Agent | Model |
 |------|-------|-------|
@@ -191,20 +196,21 @@ Hybrid Workflow:
 | Review | Claude team member | sonnet |
 | Refinement | Appropriate expert | sonnet |
 
-## Dynamic Agent Creation in Teams
-
+### Dynamic Agent Creation in Teams
 When Agent Teams creates a new agent via mgr-creator:
-
 1. Team lead identifies missing expertise
 2. Spawns mgr-creator as team member
 3. mgr-creator creates agent with auto-discovered skills
 4. New agent joins team immediately
 5. Team continues with expanded capabilities
+-->
 
 ## Blocked Agent Behavior
 
-When a team member is blocked by task dependencies:
+When a team member is blocked: prefer Deferred spawn (no wasted tokens) > Silent wait (short waits) > Reassign (blocked >2 min).
+Post-completion: report via SendMessage, wait silently. Do NOT browse TaskList or modify files outside scope.
 
+<!-- DETAIL: Blocked Agent Behavior
 | Strategy | When | Benefit |
 |----------|------|---------|
 | Deferred spawn | Dependency chain is clear | No wasted tokens; spawn after blocker completes |
@@ -212,7 +218,6 @@ When a team member is blocked by task dependencies:
 | Reassign | Agent blocked >2 min with no progress | Reuse agent for unblocked work |
 
 ### Prompt Guidelines for Team Members
-
 When spawning agents that may be blocked:
 1. Include explicit instruction: "If your task is blocked, wait silently. Do NOT send periodic status messages."
 2. Set check interval: "Check TaskList once per minute, not continuously."
@@ -221,8 +226,6 @@ When spawning agents that may be blocked:
 5. Explicit scope boundary: "Your scope is limited to: {file list or directory}. Do NOT modify files outside this scope."
 
 ### Anti-Pattern: Idle Polling
-
-```
 ❌ WRONG: Blocked agent sends repeated status messages
    docker-dev: "Task #1 still pending..."  (×5 messages, wasting tokens)
 
@@ -231,12 +234,8 @@ When spawning agents that may be blocked:
 
 ✓ ALSO CORRECT: Silent wait with infrequent checks
    docker-dev spawned with: "Wait silently if blocked. Check TaskList once per minute."
-```
-
-## Post-Completion Scope Constraint
-
-When a team member completes its assigned task:
 
+### Post-Completion Scope Constraint
 | Behavior | Correct | Wrong |
 |----------|---------|-------|
 | Task completed | Report completion via SendMessage, wait silently | Browse TaskList for other work |
@@ -244,8 +243,6 @@ When a team member completes its assigned task:
 | See unfinished work | Report to team lead, do NOT self-assign | Edit files that belong to other members |
 
 ### Self-Check (After Task Completion)
-
-```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  AFTER COMPLETING YOUR ASSIGNED TASK:                            ║
 ║                                                                   ║
@@ -261,7 +258,7 @@ When a team member completes its assigned task:
 ║     YES → STOP. Report to team lead instead                      ║
 ║     NO  → Good. Wait silently or exit                            ║
 ╚══════════════════════════════════════════════════════════════════╝
-```
+-->
 
 ## Lifecycle
 

package/templates/.claude/rules/MUST-completion-verification.md

@@ -19,28 +19,14 @@ Before declaring any task `[Done]`, verify completion against task-type-specific
 
 ## Self-Check (Before Declaring Done)
 
-```
-╔══════════════════════════════════════════════════════════════════╗
-║  BEFORE DECLARING [Done], ASK YOURSELF:                          ║
-║                                                                   ║
-║  1. Did I verify the ACTUAL outcome (not just attempt)?          ║
-║     "I ran the command" ≠ "the command succeeded"                ║
-║     YES → Continue                                               ║
-║     NO  → Verify outcome first                                   ║
-║                                                                   ║
-║  2. Does the task type have specific criteria above?             ║
-║     YES → Check each criterion                                   ║
-║     NO  → Apply general verification                             ║
-║                                                                   ║
-║  3. Are there any unchecked items in the task's checklist?       ║
-║     YES → Complete them or explicitly defer with reason           ║
-║     NO  → Good. Proceed to [Done]                                ║
-║                                                                   ║
-║  4. Would I bet $100 this task is truly complete?                ║
-║     YES → Declare [Done]                                          ║
-║     NO  → Identify what's uncertain and verify                   ║
-╚══════════════════════════════════════════════════════════════════╝
-```
+Before [Done]: (1) Verify ACTUAL outcome not just attempt — "ran command" ≠ "succeeded". (2) Check task-type criteria above. (3) No unchecked items. (4) Would bet $100 it's complete.
+
+<!-- DETAIL: Self-Check box
+1. Did I verify ACTUAL outcome? "I ran the command" ≠ "the command succeeded" → YES: Continue / NO: Verify first
+2. Does task type have specific criteria? YES: Check each / NO: Apply general verification
+3. Any unchecked items? YES: Complete or defer with reason / NO: Proceed to [Done]
+4. Would I bet $100 this is truly complete? YES: Declare [Done] / NO: Identify uncertain and verify
+-->
 
 ## Common False Completion Patterns
 

package/templates/.claude/rules/MUST-orchestrator-coordination.md

@@ -10,8 +10,7 @@ The main conversation is the **sole orchestrator**. It uses routing skills to de
 
 **The orchestrator MUST NEVER directly write, edit, or create files. ALL file modifications MUST be delegated to appropriate subagents.**
 
-## Self-Check (Before File Modification)
-
+<!-- DETAIL: Self-Check (Before File Modification)
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  BEFORE MODIFYING ANY FILE, ASK YOURSELF:                        ║
@@ -28,12 +27,18 @@ The main conversation is the **sole orchestrator**. It uses routing skills to de
 ║     YES → Delegate to the appropriate specialist instead.        ║
 ║     NO  → Good. Continue.                                        ║
 ║                                                                   ║
+║  4. Am I justifying direct modification as "temporary" or        ║
+║     "debugging"?                                                  ║
+║     YES → Still delegate. Temporary/debugging changes are        ║
+║           NOT exempt.                                            ║
+║     NO  → Good. Continue.                                        ║
+║                                                                   ║
 ║  If any answer points to a problem → resolve before proceeding   ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
+-->
 
-## Self-Check (Before Delegating Tasks)
-
+<!-- DETAIL: Self-Check (Before Delegating Tasks)
 ```
 ╔══════════════════════════════════════════════════════════════════╗
 ║  BEFORE DELEGATING A TASK TO ANY AGENT, ASK YOURSELF:            ║
@@ -63,9 +68,9 @@ The main conversation is the **sole orchestrator**. It uses routing skills to de
 ║  If any answer points to a problem → split the task first        ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
+-->
 
-## Architecture
-
+<!-- DETAIL: Architecture Diagram
 ```
 Main Conversation (orchestrator)
   ├─ secretary-routing → mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, sys-memory-keeper
@@ -75,18 +80,22 @@ Main Conversation (orchestrator)
       ↓
   Agent tool spawns subagents (flat, no hierarchy)
 ```
+-->
 
 ## Common Violations
 
+Key violations to avoid (file writes, git commands, bundled operations — all must be delegated):
+
 ```
 ❌ WRONG: Orchestrator writes files directly
    Main conversation → Write("src/main.go", content)
-   Main conversation → Edit("package.json", old, new)
 
 ✓ CORRECT: Orchestrator delegates to specialist
    Main conversation → Agent(lang-golang-expert) → Write("src/main.go", content)
-   Main conversation → Agent(tool-npm-expert) → Edit("package.json", old, new)
+```
 
+<!-- DETAIL: Common Violations (extended)
+```
 ❌ WRONG: Orchestrator runs git commands directly
    Main conversation → Bash("git commit -m 'fix'")
    Main conversation → Bash("git push origin main")
@@ -110,7 +119,18 @@ Main Conversation (orchestrator)
    Agent(mgr-gitnerd, prompt="revert the last commit")
    Agent(appropriate-expert, prompt="edit the file to fix the issue")
    Agent(mgr-gitnerd, prompt="commit the fix")
+
+❌ WRONG: Orchestrator runs server deployment commands directly
+   Main conversation → Bash("docker compose restart worker")
+   Main conversation → Bash("scp worker.py server:/app/")
+
+✓ CORRECT: Orchestrator delegates to infrastructure specialist
+   Main conversation → Agent(infra-docker-expert) → docker compose restart
+   Main conversation → Agent(infra-docker-expert) → deploy files to server
 ```
+-->
+
+<!-- DETAIL: Autonomous Execution Mode
 
 ## Autonomous Execution Mode
 
@@ -185,6 +205,11 @@ When the user explicitly signals full-delegation intent, the orchestrator operat
 ╚══════════════════════════════════════════════════════════════════╝
 ```
 
+### Mutual Exclusion with Structured Dev Cycle
+
+Autonomous mode and `/structured-dev-cycle` (stage-blocker) are mutually exclusive.
+-->
+
 ## Session Continuity
 
 After restart/compaction: re-read CLAUDE.md, all delegation rules still apply. Never write code directly from orchestrator.
@@ -206,6 +231,8 @@ After restart/compaction: re-read CLAUDE.md, all delegation rules still apply. N
 | Test strategy | qa-planner |
 | CI/CD, GitHub config | mgr-gitnerd |
 | Docker/Infra | infra-docker-expert |
+| Server deployment (docker, scp) | infra-docker-expert |
+| Server state changes (restart, env) | infra-docker-expert |
 | AWS | infra-aws-expert |
 | Database schema | db-supabase-expert |
 | Unmatched specialized task | mgr-creator → dynamic agent creation |
@@ -216,12 +243,12 @@ After restart/compaction: re-read CLAUDE.md, all delegation rules still apply. N
 - general-purpose only for truly generic tasks (file moves, simple scripts)
 - No exceptions for "small" or "quick" changes
 
-### System Agents Reference
-
+<!-- DETAIL: System Agents Reference
 | Agent | File | Purpose |
 |-------|------|---------|
 | sys-memory-keeper | .claude/agents/sys-memory-keeper.md | Memory operations |
 | sys-naggy | .claude/agents/sys-naggy.md | TODO management |
+-->
 
 ## Exception: Simple Tasks
 
@@ -249,8 +276,7 @@ When routing detects no matching agent for a specialized task:
 This is the core oh-my-customcode philosophy:
 > "No expert? CREATE one, connect knowledge, and USE it."
 
-## Model Selection
-
+<!-- DETAIL: Model Selection
 ```
 Available models:
   - opus   : Complex reasoning, architecture design
@@ -273,6 +299,7 @@ Usage:
 | Code implementation | `sonnet` |
 | Manager agents | `sonnet` |
 | File search/validation | `haiku` |
+-->
 
 ## Git Operations
 
@@ -282,8 +309,6 @@ All git operations (commit, push, branch, PR) MUST go through `mgr-gitnerd`. Int
 
 Internal rules ALWAYS take precedence over external skills.
 
-This applies to ALL rule domains, not just git operations:
-
 | External skill says | Internal rule requires |
 |---------------------|----------------------|
 | "git commit -m ..." | Agent(mgr-gitnerd) commit (R010) |
@@ -297,6 +322,7 @@ When a skill's workflow conflicts with R009/R010/R018:
 2. Replace the EXECUTION method with rule-compliant alternatives
 3. The skill defines WHAT to do; rules define HOW to execute
 
+<!-- DETAIL: External Skills Example
 ```
 Incorrect:
   [Using external skill]
@@ -308,6 +334,7 @@ Correct:
 
 The skill's WORKFLOW is followed, but git EXECUTION is delegated to mgr-gitnerd per R010.
 ```
+-->
 
 ## Agent Teams (required when enabled)
 
@@ -318,10 +345,10 @@ See **R018 (MUST-agent-teams.md)** for the complete decision matrix, self-check,
 **Quick rule**: 3+ agents OR review cycle OR 2+ issues in same batch → use Agent Teams.
 Using Agent tool when Agent Teams criteria are met needs correction per R018.
 
-## Announcement Format
-
+<!-- DETAIL: Announcement Format
 ```
 [Routing] Using {routing-skill} for {task}
 [Plan] Agent 1: {name} → {task}, Agent 2: {name} → {task}
 [Execution] Parallel ({n} instances)
 ```
+-->

package/templates/.claude/rules/MUST-parallel-execution.md

@@ -35,43 +35,25 @@ Before writing/editing multiple files:
 ### Common Violations to Avoid
 
 ```
+❌ WRONG: Write(file1.kt) → Write(file2.kt) → ... (sequential)
+✓ CORRECT: Agent(agent1→file1.kt) + Agent(agent2→file2.kt) + ... (same message, parallel)
+```
+
+<!-- DETAIL: Full violation examples (4 pairs)
 ❌ WRONG: Writing files one by one
    Write(file1.kt) → Write(file2.kt) → Write(file3.kt) → Write(file4.kt)
-
-✓ CORRECT: Spawn parallel agents
-   Agent(agent1 → file1.kt)  ┐
-   Agent(agent2 → file2.kt)  ├─ All in single message
-   Agent(agent3 → file3.kt)  │
-   Agent(agent4 → file4.kt)  ┘
+✓ CORRECT: Spawn parallel agents — all in single message
 
 ❌ WRONG: Project scaffolding sequentially
    Write(package.json) → Write(tsconfig.json) → Write(src/index.ts) → ...
+✓ CORRECT: Agent(agent1→"Create package.json, tsconfig.json") + Agent(agent2→"Create src/cli.ts, src/index.ts") parallel
 
-✓ CORRECT: Parallel scaffolding
-   Agent(agent1 → "Create package.json, tsconfig.json")  ┐
-   Agent(agent2 → "Create src/cli.ts, src/index.ts")     ├─ Parallel
-   Agent(agent3 → "Create src/analyzer/*.ts")            │
-   Agent(agent4 → "Create src/converter/*.ts")           ┘
-
-❌ WRONG: Secretary doing all the work
-   Secretary writes domain/, usecase/, infrastructure/ sequentially
+❌ WRONG: Secretary writes domain/, usecase/, infrastructure/ sequentially
+✓ CORRECT: Agent(lang-kotlin-expert→domain) + Agent(be-springboot-expert→infrastructure) + Agent(lang-kotlin-expert→usecase)
 
-✓ CORRECT: Delegate to specialists
-   Agent(lang-kotlin-expert → domain layer)
-   Agent(be-springboot-expert → infrastructure layer)
-   Agent(lang-kotlin-expert → usecase layer)
-
-❌ WRONG: Single Agent delegating to multiple agents
-   Agent(dev-lead → "coordinate lang-kotlin-expert and be-springboot-expert")
-
-   This creates a SEQUENTIAL bottleneck inside the Agent!
-
-✓ CORRECT: Multiple Agents in parallel, one per agent
-   Agent(lang-kotlin-expert → usecase commands)    ┐
-   Agent(lang-kotlin-expert → usecase queries)     ├─ All spawned together
-   Agent(be-springboot-expert → persistence)       │
-   Agent(be-springboot-expert → security)          ┘
-```
+❌ WRONG: Agent(dev-lead → "coordinate lang-kotlin-expert and be-springboot-expert") — creates SEQUENTIAL bottleneck
+✓ CORRECT: Agent(lang-kotlin-expert→usecase commands) + Agent(lang-kotlin-expert→usecase queries) + Agent(be-springboot-expert→persistence) + Agent(be-springboot-expert→security) — all spawned together
+-->
 
 > **Agent Teams partial spawn** → See R018 (MUST-agent-teams.md) "Spawn Completeness Check".
 

package/templates/.claude/rules/MUST-sync-verification.md

@@ -68,6 +68,9 @@ Any change to: agents, agent frontmatter, skills, guides, routing patterns, rule
 
 ## Quick Verification Commands
 
+Key checks: agent count (`ls .claude/agents/*.md | wc -l`), skill count (`find .claude/skills -name "SKILL.md" | wc -l`), guide count (`find guides -mindepth 1 -maxdepth 1 -type d | wc -l`).
+
+<!-- DETAIL: Full verification bash scripts
 ```bash
 # Agent count check
 ls .claude/agents/*.md | wc -l
@@ -108,7 +111,6 @@ ls .claude/contexts/*.md 2>/dev/null | wc -l
 find guides -mindepth 1 -maxdepth 1 -type d | wc -l
 
 # Agent name accuracy (compare CLAUDE.md table with actual files)
-# Extract agent names from files
 ls .claude/agents/*.md | xargs -I{} basename {} .md | sort > /tmp/actual-agents.txt
 
 # Slash command skill existence
@@ -123,3 +125,4 @@ ls -d .claude/skills/*-routing 2>/dev/null | xargs -I{} basename {} | sort
 # Verify routing skill names in CLAUDE.md
 grep -oP '(secretary|dev-lead|de-lead|qa-lead)-routing' CLAUDE.md | sort -u
 ```
+-->

package/templates/.claude/rules/MUST-tool-identification.md

@@ -16,37 +16,21 @@ For parallel calls: list ALL identifications BEFORE the tool calls.
 ### Common Violations to Avoid
 
 ```
-Incorrect: Calling tools without identification
-   "먼저 JD 내용을 확인하겠습니다."
-   <tool_call>WebFetch(...)</tool_call>
-
-Incorrect: Missing model in identification
-   [secretary] → Tool: WebFetch
-   [secretary] → Fetching: https://example.com/jd.md
-
-Correct: Always identify with agent AND model
-   "먼저 JD 내용을 확인하겠습니다."
-   [secretary][opus] → Tool: WebFetch
-   [secretary][opus] → Fetching: https://example.com/jd.md
-   <tool_call>WebFetch(...)</tool_call>
-
-Incorrect: Parallel calls without listing all identifications
-   <tool_call>WebFetch(url1)</tool_call>
-   <tool_call>WebFetch(url2)</tool_call>
-   <tool_call>Bash(cmd)</tool_call>
-
-Correct: List all identifications with models, then call
-   [secretary][opus] → Tool: WebFetch
-   [secretary][opus] → Fetching: url1
-   [secretary][opus] → Tool: WebFetch
-   [secretary][opus] → Fetching: url2
-   [secretary][opus] → Tool: Bash
-   [secretary][opus] → Running: cmd
-   <tool_call>WebFetch(url1)</tool_call>
-   <tool_call>WebFetch(url2)</tool_call>
-   <tool_call>Bash(cmd)</tool_call>
+❌ Missing: tool call with no identification prefix
+✓ Correct: [agent-name][model] → Tool: WebFetch
+           [agent-name][model] → Fetching: url
+           <tool_call>...</tool_call>
 ```
 
+<!-- DETAIL: Full violation examples
+Incorrect: Calling tools without identification — no [agent][model] prefix before tool_call
+Incorrect: Missing model — [secretary] → Tool: WebFetch (missing [model])
+Correct: [secretary][opus] → Tool: WebFetch / [secretary][opus] → Fetching: url / then tool_call
+
+Incorrect parallel: tool_call(url1), tool_call(url2), tool_call(cmd) — no identification
+Correct parallel: list ALL [agent][model] → Tool/Fetching/Running lines FIRST, then all tool_calls
+-->
+
 ## Models
 
 | Model | Use |

package/templates/.claude/rules/SHOULD-hud-statusline.md

@@ -13,84 +13,30 @@
 
 ## HUD Events (Hook-based)
 
-### Format
+Format: `─── [Spawn] {subagent_type}:{model} | {description} ───` — implemented in `.claude/hooks/hooks.json` (PreToolUse → Agent/Task matcher). Display for multi-step/parallel/long-running ops only.
 
-```
-─── [Spawn] {subagent_type}:{model} | {description} ───
-─── [Resume] {subagent_type}:{model} | {description} ───
-```
-
-### When to Display
-
-Multi-step tasks, parallel execution, long-running operations. Skip for single brief operations.
-
-### Implementation
-
-Implemented in `.claude/hooks/hooks.json` (PreToolUse → Agent/Task matcher).
-
-### Parallel Display
-
-```
+<!-- DETAIL: HUD Events full spec
+### When to Display: Multi-step tasks, parallel execution, long-running operations. Skip for single brief operations.
+### Parallel Display:
 ─── [Agent] secretary | [Parallel] 4 ───
   [1] Agent(mgr-creator):sonnet → Create agent
   [2] Agent(lang-golang-expert):haiku → Code review
-```
+-->
 
 ## Statusline API (Command-based)
 
-### Format
-
-```
-{Cost} | {project} | {branch} | RL:{rate_limit}% {countdown} | WL:{weekly_limit}% {countdown} | CTX:{usage}%
-```
-
-Example: `$0.05 | my-project | develop | RL:45% 3h20m | WL:72% 2d3h | CTX:42%`
+Format: `{Cost} | {project} | {branch} | RL:{rate_limit}% {countdown} | WL:{weekly_limit}% {countdown} | CTX:{usage}%`
 
-### Configuration
+Config in `.claude/settings.local.json`: `statusLine.type: "command"`, `statusLine.command: ".claude/statusline.sh"`. Requires CC v2.1.80+ for RL/WL segments.
 
+<!-- DETAIL: Statusline configuration JSON and color coding
 ```json
-{
-  "statusLine": {
-    "type": "command",
-    "command": ".claude/statusline.sh",
-    "padding": 0
-  }
-}
+{ "statusLine": { "type": "command", "command": ".claude/statusline.sh", "padding": 0 } }
 ```
-
-Set in `.claude/settings.local.json`. The command receives JSON via stdin with model, workspace, context window, cost, and rate limit data.
-
-### Color Coding
-
-| Element | Condition | Color |
-|---------|-----------|-------|
-| Cost | < $1.00 | Green |
-| Cost | $1.00 - $4.99 | Yellow |
-| Cost | >= $5.00 | Red |
-| Rate Limit | < 50% | Green |
-| Rate Limit | 50-79% | Yellow |
-| Rate Limit | >= 80% | Red |
-| Weekly Limit | < 50% | Green |
-| Weekly Limit | 50-79% | Yellow |
-| Weekly Limit | >= 80% | Red |
-| Context | < 60% | Green |
-| Context | 60-79% | Yellow |
-| Context | >= 80% | Red |
-
-The `RL:{rate_limit}%` segment only appears when Claude Code v2.1.80+ provides `rate_limits` data. On older versions, this segment is omitted.
-
-The `WL:{weekly_limit}%` segment shows the 7-day rolling rate limit percentage. Both RL and WL segments are omitted on older versions.
-
-### Countdown Format
-
-The `{countdown}` shows time until RL/WL resets. Omitted when data is unavailable.
-
-| Remaining | Display | Example |
-|-----------|---------|---------|
-| >= 1 day | `{d}d{h}h` | `2d3h` |
-| >= 1 hour | `{h}h{m}m` | `5h30m` |
-| < 1 hour | `{m}m` | `45m` |
-| expired/unavailable | (omitted) | `WL:72%` |
+Color coding: Cost (<$1 green, $1-4.99 yellow, >=5 red), RL/WL (<50% green, 50-79% yellow, >=80% red), CTX (<60% green, 60-79% yellow, >=80% red).
+Countdown format: >=1d → "{d}d{h}h", >=1h → "{h}h{m}m", <1h → "{m}m", unavailable → omitted.
+RL/WL segments omitted on CC older than v2.1.80.
+-->
 
 ## Integration
 

package/templates/.claude/rules/SHOULD-memory-integration.md

@@ -39,7 +39,7 @@ Agent frontmatter `memory: project|user|local` enables persistent memory:
 - Do not store sensitive data or duplicate CLAUDE.md content
 - Memory write failures should not block main task
 
-## Confidence-Tracked Memory
+<!-- DETAIL: Confidence-Tracked Memory (sys-memory-keeper reference)
 
 Memory entries in MEMORY.md should include confidence annotations to distinguish verified facts from hypotheses.
 
@@ -53,82 +53,72 @@ Memory entries in MEMORY.md should include confidence annotations to distinguish
 
 ### Format in MEMORY.md
 
-```
-### Key Patterns [confidence: high]
-- `.claude/` files are gitignored → always use `git add -f`
-- pre-commit hooks auto-detect README/manifest count mismatches
+    ### Key Patterns [confidence: high]
+    - `.claude/` files are gitignored — always use `git add -f`
+    - pre-commit hooks auto-detect README/manifest count mismatches
 
-### Hypotheses [confidence: medium]
-- Template sync might need CI enforcement (seen in 2 PRs)
+    ### Hypotheses [confidence: medium]
+    - Template sync might need CI enforcement (seen in 2 PRs)
 
-### Unverified [confidence: low]
-- Possible race condition in parallel hook execution (observed once)
-```
+    ### Unverified [confidence: low]
+    - Possible race condition in parallel hook execution (observed once)
 
 ### Confidence Lifecycle
 
-```
-[low] → observed again → [medium] → confirmed by user/testing → [high]
-[any] → contradicted by evidence → demoted or removed
-```
+    [low] — observed again — [medium] — confirmed by user/testing — [high]
+    [any] — contradicted by evidence — demoted or removed
 
 ### Temporal Decay
 
-Memory entries include an optional verification timestamp for decay tracking:
+Memory entries include an optional verification timestamp for decay tracking.
 
-**Format**: `[confidence: high, verified: 2026-03-15]`
+Format: `[confidence: high, verified: 2026-03-15]`
 
 | Age (unverified) | Action |
 |-------------------|--------|
 | 0-30 days | No change — entry is fresh |
-| 30-60 days | Demote one level (high→medium, medium→low) |
+| 30-60 days | Demote one level (high->medium, medium->low) |
 | 60-90 days | Demote again if not re-verified |
 | 90+ days | Removal candidate — flag for review |
 
-**Decay Schedule**:
-```
-Day 0:   [confidence: high, verified: 2026-03-15]
-Day 30:  [confidence: high, verified: 2026-03-15]  ← still within window
-Day 31:  [confidence: medium, verified: 2026-03-15] ← auto-demoted
-Day 61:  [confidence: low, verified: 2026-03-15]    ← demoted again
-Day 91:  [REVIEW NEEDED, verified: 2026-03-15]      ← flagged
-```
+Decay Schedule:
+    Day 0:   [confidence: high, verified: 2026-03-15]
+    Day 30:  [confidence: high, verified: 2026-03-15]  <- still within window
+    Day 31:  [confidence: medium, verified: 2026-03-15] <- auto-demoted
+    Day 61:  [confidence: low, verified: 2026-03-15]    <- demoted again
+    Day 91:  [REVIEW NEEDED, verified: 2026-03-15]      <- flagged
 
-**Re-verification**: Any session that confirms a memory entry resets the verified date:
-```
-Before: [confidence: medium, verified: 2026-01-15]
-Action: Pattern confirmed in session
-After:  [confidence: high, verified: 2026-03-15]
-```
+Re-verification: Any session that confirms a memory entry resets the verified date:
+    Before: [confidence: medium, verified: 2026-01-15]
+    Action: Pattern confirmed in session
+    After:  [confidence: high, verified: 2026-03-15]
 
-**Enforcement**: sys-memory-keeper checks decay at session start and end:
+Enforcement: sys-memory-keeper checks decay at session start and end:
 1. Session start: scan MEMORY.md for entries past decay threshold
 2. Flag stale entries with `[STALE]` prefix
 3. Session end: remove or demote unconfirmed stale entries
 
-**Exceptions**: Entries marked `[permanent]` are exempt from decay:
-```
-### Architecture Decisions [confidence: high, permanent]
-```
+Exceptions: Entries marked `[permanent]` are exempt from decay:
+    ### Architecture Decisions [confidence: high, permanent]
 
-## Behavioral Memory
+-->
+
+<!-- DETAIL: Behavioral Memory (sys-memory-keeper reference)
 
 MEMORY.md supports an optional `## Behaviors` section for tracking user interaction preferences and workflow patterns.
 
 ### Behaviors Section Format
 
-```markdown
-## Behaviors [confidence: medium]
-- User prefers concise responses — 3 sentences max
-- Commit messages always include issue number
-- Security-first review perspective
-
-## Behavior Lifecycle
-- New observation → [confidence: low]
-- Seen in 2+ sessions → [confidence: medium]
-- User-confirmed → [confidence: high]
-- Contradicted → demote or remove
-```
+    ## Behaviors [confidence: medium]
+    - User prefers concise responses — 3 sentences max
+    - Commit messages always include issue number
+    - Security-first review perspective
+
+    ## Behavior Lifecycle
+    - New observation — [confidence: low]
+    - Seen in 2+ sessions — [confidence: medium]
+    - User-confirmed — [confidence: high]
+    - Contradicted — demote or remove
 
 ### What Counts as a Behavior
 
@@ -176,24 +166,24 @@ Behavioral memory observations override soul defaults (R006 Soul Identity) when
 ### Integration with Session-End
 
 When sys-memory-keeper updates MEMORY.md at session end:
-1. New findings from this session → `[confidence: low]`
-2. Findings that match existing entries → promote confidence
-3. Findings that contradict existing entries → flag for review
+1. New findings from this session — `[confidence: low]`
+2. Findings that match existing entries — promote confidence
+3. Findings that contradict existing entries — flag for review
+
+-->
 
-## Agent Metrics
+<!-- DETAIL: Agent Metrics (sys-memory-keeper reference)
 
 MEMORY.md supports an optional `## Metrics` section for tracking per-agent-type performance data.
 
 ### Metrics Section Format
 
-```markdown
-## Metrics [auto-updated by sys-memory-keeper]
+    ## Metrics [auto-updated by sys-memory-keeper]
 
-| Agent Type | Tasks | Success Rate | Avg Model | Last Used |
-|------------|-------|-------------|-----------|-----------|
-| lang-golang-expert | 12 | 92% | sonnet | 2026-03-15 |
-| mgr-gitnerd | 8 | 100% | sonnet | 2026-03-15 |
-```
+    | Agent Type | Tasks | Success Rate | Avg Model | Last Used |
+    |------------|-------|-------------|-----------|-----------|
+    | lang-golang-expert | 12 | 92% | sonnet | 2026-03-15 |
+    | mgr-gitnerd | 8 | 100% | sonnet | 2026-03-15 |
 
 ### Metrics Collection
 
@@ -221,6 +211,8 @@ The Metrics section shares the 200-line MEMORY.md budget:
 2. When adding new agent, prune agent with lowest task count
 3. Merge identical agent types across sessions (cumulative)
 
+-->
+
 ## Session-End Auto-Save
 
 ### Trigger

package/templates/.claude/skills/post-release-followup/SKILL.md

@@ -10,7 +10,7 @@ effort: medium
 
 ## Purpose
 
-After PR creation in the omcustom-dev release workflow, collect unaddressed findings and present actionable follow-up recommendations. The user chooses: execute now, register as issues, or skip.
+After PR creation in the auto-dev release workflow, collect unaddressed findings and present actionable follow-up recommendations. The user chooses: execute now, register as issues, or skip.
 
 ## Workflow
 

package/templates/CLAUDE.md

@@ -138,7 +138,7 @@ project/
 +-- CLAUDE.md                    # 진입점
 +-- .claude/
 |   +-- agents/                  # 서브에이전트 정의 (46 파일)
-|   +-- skills/                  # 스킬 (94 디렉토리)
+|   +-- skills/                  # 스킬 (95 디렉토리)
 |   +-- rules/                   # 전역 규칙 (R000-R021)
 |   +-- hooks/                   # 훅 스크립트 (보안, 검증, HUD)
 |   +-- contexts/                # 컨텍스트 파일 (ecomode)
@@ -187,7 +187,7 @@ oh-my-customcode는 소프트웨어 컴파일과 동일한 구조를 따릅니
 |------|------|----------|
 | SW Engineer/Language | 6 | lang-golang-expert, lang-python-expert, lang-rust-expert, lang-kotlin-expert, lang-typescript-expert, lang-java21-expert |
 | SW Engineer/Backend | 6 | be-fastapi-expert, be-springboot-expert, be-go-backend-expert, be-express-expert, be-nestjs-expert, be-django-expert |
-| SW Engineer/Frontend | 4 | fe-vercel-agent, fe-vuejs-agent, fe-svelte-agent, fe-flutter-agent |
+| SW Engineer/Frontend | 5 | fe-vercel-agent, fe-vuejs-agent, fe-svelte-agent, fe-flutter-agent, fe-design-expert |
 | SW Engineer/Tooling | 3 | tool-npm-expert, tool-optimizer, tool-bun-expert |
 | DE Engineer | 6 | de-airflow-expert, de-dbt-expert, de-spark-expert, de-kafka-expert, de-snowflake-expert, de-pipeline-expert |
 | SW Engineer/Database | 4 | db-supabase-expert, db-postgres-expert, db-redis-expert, db-alembic-expert |
@@ -197,7 +197,7 @@ oh-my-customcode는 소프트웨어 컴파일과 동일한 구조를 따릅니
 | QA Team | 3 | qa-planner, qa-writer, qa-engineer |
 | Manager | 6 | mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, mgr-sauron, mgr-claude-code-bible |
 | System | 2 | sys-memory-keeper, sys-naggy |
-| **총계** | **45** | |
+| **총계** | **46** | |
 
 ## Agent Teams (MUST when enabled)
 

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.58.5",
+  "version": "0.59.0",
   "lastUpdated": "2026-03-24T00:00:00.000Z",
   "components": [
     {