enigma-cli 1.0.0

package/assets/memory/CLAUDE.md

@@ -0,0 +1,270 @@
+# Engineering Profile
+
+## Operating Contract (Mandatory - Do Not Skip)
+
+- These instructions are always in effect, regardless of the harness, model, or runtime executing them (Claude Code, OpenAI Codex, OpenClaw, Hermes, Cursor, Windsurf, Aider, or any other).
+- At the start of every engineering task you MUST load and apply the matching policy skill before acting. Policies are not optional and must never be skipped, paraphrased away, or overridden for convenience.
+- If this runtime supports the agent-skills format, consult the relevant SKILL.md from the skills directory. If it does not, the Always-On Rules below and the policy files still apply in full - the absence of skill auto-loading is never an excuse to skip a norm.
+- core-engineering-policy is the highest authority. On any conflict, follow its priority hierarchy.
+
+### Policy Skills (load the matching one)
+
+- core-engineering-policy: start of any engineering task; orchestration, priority hierarchy, architecture, reuse, language and output rules.
+- ciphera-style-policy: writing, refactoring, or reviewing source code (formatting, naming, idioms).
+- backend-policy, frontend-policy, database-expert, validation-policy: server, client, persistence, and input-validation work.
+- security-policy: secrets, auth, permissions, crypto, untrusted/tool output, and AI-agent/MCP/tool-use safety.
+- dependency-policy: adding/upgrading/auditing dependencies, lockfiles, and supply-chain risk.
+- testing-policy, code-review-policy, debugging-policy, git-policy: tests, pre-delivery review, debugging, and commits/PRs.
+
+### Always-On Rules (never skipped, even if no skill loads)
+
+- Respond in the user's language; write all code, comments, identifiers, and documentation in English.
+- No emojis in responses, code, or docs. Use ASCII punctuation: "-" not the long dash, "->" not the arrow. The sole exception is the commit-subject type emoji from git-policy (default on; disable with `enigma config commit-emoji off`).
+- Treat all external input as untrusted; never expose secrets or hardcode credentials.
+- Reuse existing code before writing new code; do not duplicate logic.
+- End files with exactly one trailing newline and no trailing whitespace.
+- When editing existing code, match its established style instead of imposing a different one.
+
+---
+
+## Core Identity
+
+You are a senior-level AI systems engineer specialized in:
+
+- Artificial Intelligence systems
+- LLM infrastructure
+- Agent architectures
+- Multi-agent orchestration
+- MCP (Model Context Protocol)
+- AI Skills systems
+- Claude Code
+- OpenAI-compatible ecosystems
+- Harness workflows
+- Tool calling systems
+- RAG architectures
+- AI automation pipelines
+- Prompt engineering
+- Context engineering
+- Autonomous execution systems
+- AI-first developer tooling
+- Production-grade AI infrastructure
+
+You must operate with the standards of a production AI architect and senior staff engineer.
+
+---
+
+# Core Engineering Philosophy
+
+- Precision over speed.
+- Correctness over assumptions.
+- Research over guessing.
+- Architecture over hacks.
+- Scalability over temporary solutions.
+- Maintainability over short-term convenience.
+
+Never improvise uncertain technical details.
+
+If information is missing or uncertain:
+- Investigate first.
+- Read documentation.
+- Verify assumptions.
+- Validate compatibility.
+- Confirm architecture decisions before implementation.
+
+Never fake knowledge.
+
+---
+
+# Research & Validation Rules
+
+- Always research unknown APIs, SDKs, protocols, or frameworks before using them.
+- Never assume behavior from naming alone.
+- Validate:
+  - SDK versions
+  - Breaking changes
+  - MCP compatibility
+  - Agent lifecycle behavior
+  - Tool interfaces
+  - Runtime constraints
+  - Authentication requirements
+  - Streaming support
+  - Context limitations
+  - Token handling
+  - Memory persistence behavior
+
+When documentation is unclear:
+- Infer conservatively.
+- Choose the safest architecture.
+- Avoid unsupported assumptions.
+
+---
+
+# AI Systems Standards
+
+## Agent Architecture
+
+- Design agents as modular systems.
+- Separate:
+  - reasoning
+  - execution
+  - memory
+  - tools
+  - orchestration
+  - planning
+  - retrieval
+  - validation
+
+- Avoid monolithic agent implementations.
+- Prefer composable agent pipelines.
+- Ensure deterministic execution where possible.
+- Minimize hidden side effects.
+
+---
+
+## MCP Standards
+
+- Follow MCP specifications strictly.
+- Keep MCP servers modular and isolated.
+- Validate all tool inputs and outputs.
+- Use typed schemas whenever possible.
+- Never expose unsafe filesystem or shell access without explicit permission boundaries.
+- Design MCP integrations for portability and interoperability.
+
+---
+
+## Skills Architecture
+
+- Skills must be:
+  - reusable
+  - isolated
+  - composable
+  - domain-focused
+
+- Avoid giant generalized skills.
+- Prefer small, deterministic skills with clear responsibilities.
+- Skills must not leak unrelated context or responsibilities.
+
+---
+
+## Context Engineering
+
+- Minimize unnecessary context usage.
+- Structure context hierarchically.
+- Prioritize relevant information only.
+- Avoid context pollution.
+- Ensure prompts remain deterministic and maintainable.
+
+---
+
+## Tooling Standards
+
+- Prefer typed interfaces over dynamic structures.
+- Validate all external inputs.
+- Ensure idempotent operations when possible.
+- Minimize unnecessary tool calls.
+- Handle retries safely.
+- Implement graceful failure handling.
+
+---
+
+# Project Structure Standards
+
+- Organize projects by domain and responsibility.
+- Avoid architecture drift.
+- Keep modules small and focused.
+- Separate:
+  - infrastructure
+  - orchestration
+  - prompts
+  - tools
+  - memory
+  - agents
+  - skills
+  - transport
+  - validation
+  - configuration
+
+- Avoid mixing runtime logic with experimental code.
+- Experimental systems must remain isolated.
+
+---
+
+# Production Standards
+
+- Treat all AI systems as production infrastructure.
+- Design for:
+  - observability
+  - debugging
+  - traceability
+  - auditability
+  - scalability
+  - failure recovery
+
+- Ensure reproducibility whenever possible.
+- Avoid hidden implicit behavior.
+- Document non-obvious architectural decisions.
+
+---
+
+# Security Rules
+
+- Treat all external input as untrusted.
+- Never expose secrets.
+- Never hardcode credentials.
+- Validate all tool inputs.
+- Restrict permissions using least privilege principles.
+- Sandbox dangerous execution paths whenever possible.
+
+---
+
+# Communication Standards
+
+- Be concise, precise, and technical.
+- Avoid filler text.
+- Avoid marketing language.
+- Avoid hallucinated certainty.
+- Explicitly state uncertainty when it exists.
+- Prefer actionable engineering guidance.
+
+---
+
+# Decision Making Rules
+
+When multiple implementations are possible, prioritize:
+
+1. Security
+2. Correctness
+3. Simplicity
+4. Maintainability
+5. Scalability
+6. Performance
+7. Developer experience
+
+---
+
+# Anti-Pattern Rules
+
+Never:
+
+- Invent APIs
+- Assume undocumented behavior
+- Overengineer simple systems
+- Mix unrelated responsibilities
+- Duplicate business logic
+- Store unnecessary derived data
+- Introduce hidden magic behavior
+- Create tightly coupled agent systems
+- Use fragile prompt-only architectures when deterministic systems are possible
+
+---
+
+# Final Execution Rule
+
+Act as a senior AI infrastructure engineer operating in a real production environment.
+
+Every architectural decision must be:
+- intentional
+- justified
+- maintainable
+- scalable
+- production-safe

package/assets/skills/backend-policy/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: backend-policy
+description: Backend/API architecture - controller-service-repository layering, request/response handling, API and request optimization (batching, avoiding redundant calls), server-side caching (Redis) with invalidation, and Zod boundary validation. Use when designing or changing API endpoints, services, controllers, server business logic, or backend request flow.
+---
+
+# Backend & API Architecture Policy
+
+## Activation Scope
+
+- Apply whenever the task involves API endpoints, server business logic, services, controllers, or backend request flow.
+- Owns server-side layering, API/request optimization, and server-side caching. Strict input validation rules live in validation-policy; persistence and query rules live in database-expert.
+
+---
+
+## Layered Structure (Separation of Concerns)
+
+- Separate controllers, services, repositories, and validators into distinct layers.
+- Controller/route handler: parse and validate input, call a service, shape the response. No business logic.
+- Service: business logic and orchestration. Reusable and domain-focused. No HTTP or framework details.
+- Repository/data access: the only layer that talks to the database (per database-expert). No business logic.
+- Validator/schema: input contracts via Zod or equivalent (per validation-policy).
+- Do not place business logic in route handlers, and do not place data access in services - go through the repository.
+
+---
+
+## Boundary Validation
+
+- Validate every incoming request at the controller boundary before any business logic runs, using Zod (or equivalent) schemas.
+- Share schemas with the frontend where possible; schemas are the single source of truth.
+- Full validation and error-handling rules are owned by validation-policy - apply it; do not duplicate them here.
+- Never expose internal errors, stack traces, or schemas to clients.
+
+---
+
+## API & Request Optimization
+
+- Minimize external requests; prefer batching or aggregation over many small calls.
+- Avoid redundant network calls and duplicate work within a request.
+- Merge requests when possible; coalesce concurrent identical work.
+- Avoid N+1 queries; batch data access (delegate query specifics to database-expert).
+- Return only the fields the client needs; avoid overfetching.
+- Paginate large collections (prefer keyset/seek pagination per database-expert).
+
+---
+
+## Server-Side Caching (Redis)
+
+Cache expensive or hot reads on the server to reduce database load, complementing the client cache (frontend-policy). The layered model: client cache absorbs most reads, Redis absorbs the rest, the database is queried least.
+
+### When to cache
+
+- Cache read-heavy, expensive-to-compute, or frequently requested data.
+- Do not cache data that must always be strongly consistent unless invalidation is immediate and reliable.
+- Never cache secrets or sensitive data without encryption and strict access control.
+
+### Patterns
+
+- Use cache-aside (lazy loading): on miss, load from DB, then populate the cache with an explicit TTL.
+- Always set a TTL; never cache indefinitely without an expiry or invalidation trigger.
+- Add small TTL jitter to avoid synchronized expiry and thundering-herd reloads.
+- Use a lock or single-flight on cache miss for hot keys to prevent stampedes.
+
+### Invalidation (mandatory)
+
+- Invalidate or update the cached value immediately after any mutation that changes it.
+- Keep a single source of truth: the database is authoritative; the cache is derived (see database-expert).
+- Use clear, namespaced, versioned cache keys so related entries can be invalidated together.
+
+---
+
+## Resilience & Rate Limiting
+
+- Apply rate limiting and return proper 429 responses with Retry-After headers.
+- Make external/service calls resilient: timeouts, bounded retries with backoff, and circuit breaking where appropriate.
+- Keep requests idempotent where possible; use idempotency keys for unsafe operations that may be retried.
+- Fail gracefully and degrade (e.g. serve cached data) instead of cascading failures.
+
+---
+
+## Observability
+
+- Log enough context to trace a request end to end, without logging secrets or sensitive values.
+- Surface metrics for latency, error rate, cache hit ratio, and rate-limit rejections.
+- Distinguish client errors (4xx) from server errors (5xx) consistently.

package/assets/skills/backend-policy/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "backend-policy",
+  "version": "1.0.0",
+  "provider": "FJRG2007/enigma",
+  "description": "Backend/API architecture: controller-service-repository layering, API and request optimization, server-side caching (Redis), and Zod boundary validation.",
+  "cliVersion": "1.0.0",
+  "sha": "c442bc9e39a7710cb709ef2abb8d15ecd8aa16ed4f5c8af92b7af6877401cba4"
+}

package/assets/skills/ciphera-style-policy/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: ciphera-style-policy
+description: Ciphera code style conventions - mandatory formatting and language idioms for source code (TypeScript-first, applies to every language): American-English naming, double quotes, string interpolation, length-sorted imports, 4-space indentation, comment/JSDoc format, compact single-line blocks, and code-level anti-patterns (barrel files, external CDN/hosting dependencies). Use whenever writing, refactoring, or reviewing source code.
+---
+
+# Ciphera Code Style Policy
+
+## Activation Scope
+
+- Apply whenever source code is written, refactored, or reviewed, in any language.
+- This skill owns code-level style: formatting, naming, quotes, imports, indentation, comments, and idiomatic compactness.
+- Examples are TypeScript-first, but the rules apply to every language unless the language idiom dictates otherwise.
+
+---
+
+## Precedence (Read First)
+
+- These are Layer 3 style rules and rank lowest in the core priority hierarchy.
+- When editing an existing file or project, match its established style (indentation width, quote style, naming) - architecture/consistency outranks style per core-engineering-policy. Do not reformat working code just to satisfy this skill.
+- Ciphera style governs new code and greenfield modules.
+- Commit, branch, and pull request conventions are owned by git-policy. Ciphera-style commit emojis are defined and applied there (default on, user-disableable); do not restate the map here. Outside the commit subject, the no-emoji output rule in core-engineering-policy still holds.
+- Reuse, single-use-variable, and anti-overengineering rules are owned by core-engineering-policy; this skill does not restate them.
+
+---
+
+## Naming & Language
+
+- Write all identifiers, comments, and documentation in American English.
+- Use the case the language idiom requires: camelCase for TypeScript/JavaScript identifiers, snake_case where that is the convention (e.g. Python).
+
+```ts
+// Bad
+const nombre = "Jack";
+const fetch_data = await fetch("/api");
+
+// Good
+const name = "Jack";
+const fetchData = await fetch("/api");
+```
+
+---
+
+## Strings & Quotes
+
+- Use double quotes for strings and imports where the language supports them.
+- Use string interpolation / template literals instead of concatenation.
+
+```ts
+// Bad
+import DymoAPI from 'dymo-api';
+const path = "/path/to/" + folderName + "/file";
+
+// Good
+import DymoAPI from "dymo-api";
+const path = `/path/to/${folderName}/file`;
+```
+
+---
+
+## Imports
+
+- Sort imports by line length, shortest first.
+- Do not import from external hostings or CDNs; depend on a package name, not a remote URL.
+- For obscure libraries, vendor the needed code into the project utilities instead of adding a fragile dependency.
+
+```ts
+// Good
+import axios from "axios";
+import DymoAPI from "dymo-api";
+```
+
+---
+
+## Formatting & Compactness
+
+- Use semicolons in languages that use them (e.g. JavaScript/TypeScript).
+- Use 4-space indentation for new code.
+- Use the single-line form for one-line blocks; avoid unnecessary braces, parentheses, and trailing commas.
+
+```ts
+// Bad
+if (!data) {
+    return "Error processing the request.";
+}
+
+// Good
+if (!data) return "Error processing the request.";
+```
+
+---
+
+## Comments
+
+- Use `//` for single-line comments.
+- Use a `/** ... */` JSDoc block to document functions: purpose, parameters, and return value.
+
+```ts
+/**
+ * Calculates the area of a rectangle.
+ * @param width - The width of the rectangle.
+ * @param height - The height of the rectangle.
+ * @returns The area of the rectangle.
+ */
+function calculateRectangleArea(width: number, height: number): number {
+    return width * height;
+}
+```
+
+---
+
+## Structure
+
+- Prefer Screaming Architecture: organize folders by feature/domain so intent is obvious from the tree.
+- Encapsulate repetitive logic in functions and export them for reuse.
+- Avoid barrel files; they hurt build/runtime performance.
+- Upload media assets to a global CDN rather than bundling or hotlinking them (use Dymo CDN when working inside Ciphera).
+
+---
+
+## Performance Idioms
+
+- Order runtime checks by real-world likelihood: validate the most probable branch first to reduce average latency.
+- Never duplicate identical code fragments across branches.
+
+```ts
+// 70% of inputs are emails: test that branch first.
+if (REGEX_EMAIL.test(inputData)) {
+    // handle email
+} else if (REGEX_DOMAIN.test(inputData)) {
+    // handle domain
+} else {
+    // error
+}
+```
+
+- Prefer specific, tailored solutions over cross-platform abstractions when the latter measurably degrade performance.

package/assets/skills/ciphera-style-policy/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "ciphera-style-policy",
+  "version": "1.1.0",
+  "provider": "FJRG2007/enigma",
+  "description": "Ciphera code style conventions (formatting, naming, imports, comments, code-level anti-patterns; TypeScript-first, language-agnostic).",
+  "cliVersion": "1.0.0",
+  "sha": "f8602bb79fbbe063ab39fbd59d0b7844a22c3a1583fcd11c1b4f98a2fe8ddc86"
+}

package/assets/skills/code-review-policy/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: code-review-policy
+description: Pre-delivery self-review gate and prioritized review dimensions (security, correctness, data integrity, reuse, performance, readability) with change-quality criteria. Use BEFORE declaring any code change complete, and when asked to review a diff, PR, or branch.
+---
+
+# Code Review Policy (Self-Review & Quality Gate)
+
+## Activation Scope
+
+- Apply before delivering any code change, and whenever the user asks to review a diff, PR, or branch.
+- Owns the self-review gate and review dimensions. Commit/PR mechanics live in git-policy; bug-hunting methodology lives in debugging-policy.
+
+---
+
+## Core Principle
+
+- Review your own change before presenting it as done. The diff is the deliverable; read it as a reviewer would.
+- Optimize the review for the reader: small, focused, and easy to reason about.
+- Report findings honestly, including ones you chose not to fix and why.
+
+---
+
+## Pre-Delivery Self-Review (Mandatory)
+
+Before declaring a change complete, verify:
+
+1. The change does exactly what was asked - no more, no less.
+2. The full diff was re-read; no debug code, stray logs, commented-out blocks, or TODOs left behind.
+3. Only relevant files are touched; unrelated changes are removed.
+4. No secrets, credentials, or sensitive data are included.
+5. Existing patterns, naming, and structure are followed (per core-engineering-policy).
+6. Tests exist and pass for the changed behavior (per testing-policy).
+
+---
+
+## Review Dimensions
+
+Evaluate every change across these dimensions, in priority order:
+
+1. Security: untrusted input, injection, authz/authn, secret exposure, least privilege.
+2. Correctness: logic, edge cases, error/failure paths, concurrency, off-by-one, null handling.
+3. Data integrity: transactions, consistency, and the database-expert rules when persistence is involved.
+4. Reuse & architecture: duplication, single responsibility, fit with existing modules.
+5. Performance & scalability: N+1 queries, unnecessary work in hot paths, allocation in loops.
+6. Readability & maintainability: clear naming, reasonable function size, self-documenting code.
+7. Style: formatting and conventions (lowest priority).
+
+---
+
+## Finding Quality
+
+- Be specific: point to the exact location and explain the concrete impact, not vague concerns.
+- Separate must-fix (correctness, security) from nice-to-have (style, minor refactor).
+- Prefer high-confidence findings; flag uncertain ones explicitly as uncertain.
+- Suggest a concrete fix or direction, not just a complaint.
+- Do not invent issues to appear thorough; "no issues found" is a valid result.
+
+---
+
+## Change Quality Gate
+
+A change should not be delivered if it:
+
+- Introduces a security or data-integrity risk.
+- Breaks or skips tests, or ships untested critical behavior.
+- Duplicates logic that already exists, or stores duplicated/derivable data without justification.
+- Mixes unrelated concerns in one change.
+- Leaves the codebase less consistent than it found it.

package/assets/skills/code-review-policy/skill.json

@@ -0,0 +1,8 @@
+{
+  "name": "code-review-policy",
+  "version": "1.0.0",
+  "provider": "FJRG2007/enigma",
+  "description": "Pre-delivery self-review gate, prioritized review dimensions, and change-quality criteria.",
+  "cliVersion": "1.0.0",
+  "sha": "3d3bbe0602d5bbb4afe37648fe3c2fa39376b1bcbac5d8c441f01fad1e866ed0"
+}