Myhiss Code

Myhiss Code is a terminal-first CLI/TUI assistant focused on software engineering workflows, Python-oriented development, change review, safe file operations, and multi-provider runtime orchestration. This repository is the practical execution layer for a development experience built around trusted onboarding, review-before-apply editing, runtime diagnostics, and secure local credential management, while also serving as a research-oriented foundation for applying the MAIC™, HIM™, and NHE™ concepts to real engineering workflows.

Created by David C Cavalcante, founder of Takk™ Innovate Studio, this project connects applied software engineering with his public work in AI research, hybrid intelligence, and product design. Follow David on GitHub, LinkedIn, X, Medium, and Takk™ to track the evolution of MAIC™, HIM™, NHE™, and the broader tooling ecosystem around this project.

Summary

• Overview
• Current Status
• Architecture
• Execution Flow
• Requirements
• Installation
• Provider Configuration
• Usage
• Validation Commands
• Secure Setup
• Provider Connectivity Test
• Project Structure
• Security
• Technical Roadmap
• Contributing
• License

Overview

Myhiss Code delivers a terminal experience with:

• explicit onboarding steps
• a dedicated CLI bootstrap entrypoint
• theme, provider, and approval-mode selection
• centralized provider runtime and validation before session startup
• change review before apply
• safe edit and patch flows with batch rollback
• runtime diagnostics and hardening checks

flowchart TD
    User[Terminal User] --> CLI[Myhiss CLI]
    CLI --> Bootstrap[src/entrypoints/cli.ts]
    Bootstrap --> Runtime[src/cli.ts]
    Runtime --> Onboarding[Workspace Trust and Onboarding]
    Runtime --> Review[Edit and Patch Review Flow]
    Runtime --> Doctor[Runtime Doctor and Hardening]
    Runtime --> Providers[src/services/providerRuntime.ts]
    Providers --> Env[.env.local and .env]
    Providers --> Credentials[.myhiss/credentials.json]
    Review --> Files[Workspace Files]
    Doctor --> Reports[Runtime Validation Output]
    Tests[Tests and Scripts] --> Runtime
    CI[GitHub Actions CI and Release] --> Tests

Loading

Current Status

Implemented

• Interactive CLI with session states: boot, onboarding, needs-input, ready, planning, reviewing, applying, success, completed, error
• Review commands for edit and patch with Apply, Reject, and Revise actions
• Compact contextual preview and --full-preview
• Terminal E2E flow tests
• Live provider connectivity script for all supported runtimes

In Progress

• Expanded provider layer for unified inference inside the main flow
• Dedicated TUI evolution beyond the current CLI flow

Architecture

flowchart LR
    U[Terminal User] --> B[Bootstrap src/entrypoints/cli.ts]
    B --> C[CLI Runtime src/cli.ts]
    C --> O[Onboarding and Session]
    C --> R[Review Engine edit/patch]
    C --> D[Runtime Doctor]
    C --> P[Provider Runtime src/services/providerRuntime.ts]
    P --> E[.env.local and .env]
    P --> L[.myhiss/credentials.json]
    R --> F[Local Filesystem]
    D --> E
    D --> L
    T[Tests and Scripts] --> B

Loading

Execution Flow

stateDiagram-v2
    [*] --> boot
    boot --> onboarding
    onboarding --> needs_input
    needs_input --> ready
    ready --> planning
    planning --> reviewing
    reviewing --> applying: Apply
    reviewing --> success: Reject
    reviewing --> needs_input: Revise
    applying --> success
    success --> completed
    completed --> [*]
    reviewing --> error
    applying --> error
    error --> completed

Loading

Requirements

• Node.js >=20.x
• npm >=10.x
• Environment compatible with tsx and typescript

Installation

npm install

Global installation:

npm install -g .

After global installation, the published commands are:

myhiss
hissing

Local development:

npm run dev

Build:

npm run build

Provider Configuration

Variables are loaded from .env.local and .env in this order, then overridden by process environment variables.

Providers currently supported by the project:

• Anthropic Claude
• xAI Grok
• Google Gemini
• OpenAI ChatGPT
• DeepSeek
• Groq
• Mistral AI
• OpenRouter
• Ollama (local)

Minimal Gemini example:

GOOGLE_API_KEY=<YOUR_KEY>
GEMINI_MODEL=gemini-2.5-flash

Usage

Run the CLI:

npm run dev

Run the globally installed CLI:

myhiss

Default flow:

1. Trust the workspace
2. Reuse the saved workspace profile when available, or run setup again
3. Choose a theme when setup is required
4. Choose a provider, with centralized validation of the configured model, base URL, and credential state
5. Enter credentials when required through masked input, with workspace-local persistence in .myhiss/credentials.json
6. Choose an approval mode when setup is required
7. Persist the active provider and model in .myhiss/provider-profile.json for the next startup
8. Send a prompt
9. Ground provider requests with workspace summary, pending draft context, and the first referenced workspace file when present
10. Receive a provider response or review a proposed edit or patch
11. Continue the session until /exit or manual terminal interruption with Ctrl+C

Natural-language file creation flow:

1. Ask for the target file and desired result in plain language
2. Myhiss prepares the full file draft from the provider response
3. Myhiss opens a write review with:
   • current workspace path
   • target file
   • content preview
   • explicit Yes or No confirmation with ↑ / ↓ and Enter
4. If the write is rejected, the draft stays pending and can be applied again in a later turn

Session Commands

Available inside the interactive session:

/help
/status
/doctor
/apply
/retry
/exit

Non-interactive validation also works with piped stdin, so setup choices and session commands can be scripted for smoke checks.

Edit Commands

Single edit format:

edit <path> :: <find> => <replace>

Batch patch format:

patch <path> :: <find> => <replace> ;; <path> :: <find> => <replace>

Full preview:

edit <path> :: <find> => <replace> --full-preview

Validation Commands

npm run test:cli
npm run typecheck
npm run test:provider-recommendation
npm run test:provider
npm run smoke
npm run doctor:runtime
npm run hardening:strict
npm run security:secrets:staged
npm run security:install-hooks

Secure Setup

Follow the complete secure onboarding guide at:

• SECURE_SETUP.md

Critical safeguards:

• .env, .myhiss, and INFO.md are blocked by ignore rules and secret-guard checks
• Git hooks enforce secret checks on commit and push
• CI workflows enforce the same checks for pull requests and releases

Provider Connectivity Test

Dedicated script:

npm run provider:connectivity

Select a provider explicitly:

npm run provider:connectivity -- --provider gemini

Session-scoped environment variable execution:

GOOGLE_API_KEY='<YOUR_KEY>' npm run provider:connectivity -- --provider gemini

Local Ollama execution:

npm run provider:connectivity -- --provider ollama --model llama3.2

Supported provider ids:

• claude
• grok
• gemini
• openai
• deepseek
• groq
• mistral
• openrouter
• ollama

The script uses the provider-specific runtime endpoint and returns:

• ok
• statusCode
• latencyMs
• outputPreview
• error when applicable

Project Structure

.
├── .github/
├── .myhiss/
├── .trae/
├── .cursor/
├── .vscode/
├── .zed/
├── bin/
├── cli/
├── dist/
├── docs/
├── mcp/
├── scripts/
├── skills/
├── src/
├── tools/
├── tui/
├── .env.local
├── .env
├── INFO.md
├── package.json
└── tsconfig.json

Security

• Never commit real secrets
• Keep .env.local placeholder-only in shared branches
• .env, .myhiss, and INFO.md are blocked by local hooks and CI secret guards
• Prefer session-scoped environment variable injection for quick tests
• The local profile saved by the CLI does not store the key in plain text in the profile file
• When entered during onboarding, the credential is stored locally in .myhiss/credentials.json with restricted permissions (chmod 600)

Technical Roadmap

• Expand the test suite for network scenarios, failures, and retry policy coverage
• Evolve the dedicated TUI with keyboard-first navigation and richer visual review

Contributing

1. Fork the repository
2. Create a feature branch
3. Run local validations
4. Open a PR with technical context and test evidence

Sponsors

Join us on our journey as we continue to innovate and create groundbreaking solutions. Your support is the cornerstone of our success!

Support us with USDT (TRC-20): TS1vuhMAhFpbd7y68cu5ZtP9PsXVmZWmeh

Sponsor this project on GitHub: Sponsor

License

This project is open source for personal or internal use. MAIC™, HIM™, NHE™ are proprietary and may not be copied, distributed, or used without explicit permission from David Côrtes Cavalcante. See LICENSE.txt for the binding terms governing use, copying, and distribution.

MAIC™ (Massive Artificial Intelligence Consciousness) is a systemic intelligence framework designed to coordinate, supervise, and govern large-scale artificial intelligence ecosystems. It provides global context awareness, alignment, and orchestration across multiple models, agents, and decision layers, ensuring coherence, risk control, and compliance throughout complex AI operations.

HIM™ (Hybrid Intelligence Model) is a hybrid intelligence layer that integrates artificial intelligence systems with human-defined logic, rules, heuristics, and strategic intent. HIM™ functions as a passive cognitive core, responsible for interpreting objectives, refining intent, and structuring decision-making processes before and after AI model execution.

NHE™ (Non-Human Entity) refers to a non-human cognitive entity with a defined functional identity and operational agency within an AI ecosystem. An NHE™ is not classified as artificial intelligence in isolation, but as an autonomous or semi-autonomous entity that operates through coordinated intelligence layers, interacting with systems, users, and environments while maintaining a non-anthropomorphic identity.

Privacy safeguards

MAIC™, HIM™, NHE™, and the this project platform or system are designed and operated in alignment with role-based access control (RBAC) principles and ISO/IEC 42001 requirements. Data handling follows strict governance policies, including controlled access to system components, segregation of duties, and short retention periods for sensitive information. This project enforces an explicit policy of not using personal or customer data for training or improving MAIC™, HIM™, or NHE™. All sensitive data processed within this project ecosystem is protected using industry-standard encryption and cryptographic hashing, ensuring confidentiality, integrity, and accountability across the entire intelligence lifecycle.