Eymia AI Community (Beta)

Eymia AI Community is a private offline VS Code AI code assistant for local LLM workflows with Ollama, Qwen Coder, LM Studio, llama.cpp, and other open-source local models. It helps with code explanation, code review, repository analysis, and workspace analysis while keeping Community beta work local and privacy-focused.

The 0.7.1 beta is intended for early feedback while the broader Pro, Team, Education, and Enterprise editions continue development.

Community Beta Scope

Community connects to local model backends and provides read-only workspace analysis, code explanation, review, conversation export, and custom skill support for one workspace root. It does not send usage telemetry to Eymia.

The Community beta does not include workspace edits, command or test execution, Git writes, remote model backends, workspace indexing, rollback history, MCP/A2A tools, web research, VEX robotics, Autonomous mode, or Multi Agent mode. Those controls are enforced by the packaged edition rather than being hidden only in the interface.

Community requires a locally running compatible model backend, such as Ollama, LM Studio, llama.cpp, or a local Hugging Face endpoint. Model quality and hardware requirements vary by model.

Install the Beta

• Marketplace identity: eymia.eymia-ai-community (publisher.name).
• Before Marketplace publication, install eymia-community-0.7.1.vsix using Extensions: Install from VSIX....
• After Marketplace publication, open the Eymia extension page, choose Switch to Pre-Release Version, and install the 0.7.x build.
• Run Eymia AI Offline Editor: Welcome, select a local backend, test the connection, and ask Eymia to explain or review code in the open workspace.

Report beta problems with Eymia AI Offline Editor: Report a Bug. The guided flow collects reproduction details, opens an editable report for review, and prepares an email to support@eymia.com; nothing is submitted automatically. It can also export a Privacy-Safe Support Bundle when diagnostic context would help. The bundle excludes prompts, file contents, workspace paths, backend URLs, credentials, and environment variables.

Community is free for personal projects, learning, evaluation, non-commercial open-source work, and individual educational use under the Eymia Community License v2.0. It is not an open-source license; commercial and managed organizational use requires the applicable paid edition or a written agreement.

Safe Working Trace 0.6.5

Version 0.6.5 shows a safe working trace automatically while Eymia is actively working or waiting for approval, then collapses it after the task stops while keeping details available to reopen. The trace summarizes observable steps, tools, approvals, and verification without exposing raw hidden model thinking or internal protocol data.

Evidence-Grounded Analysis and Hugging Face Router 0.6.4

Version 0.6.4 makes project analysis evidence-grounded instead of stopping at a file scan, hardens nested-project and Python runtime planning, and adds Hugging Face Router as a first-class remote OpenAI-compatible backend with secure token storage and model discovery. Project action cards and model capability profiles remain available across the sidebar and agent workflow.

Clone-and-Run Reliability 0.6.2

Version 0.6.2 hardens real-project setup and launch workflows. Explicit GitHub clone-and-run requests are grounded and cloned deterministically, local-only runtime phases no longer inherit unnecessary network restrictions, execution-only tasks complete from direct runtime evidence without requiring a source edit, and applications requested as running remain managed in the background. Runtime memory is opt-in so successful launches do not silently dirty the repository.

A2A External Agent Collaboration 0.4.1

Version 0.4.1 adds first-class Agent2Agent (A2A) client/delegation support without replacing MCP or Eymia Multi Agent. Configured external agents are discovered through their Agent Cards, their advertised skills become approval-gated Eymia tools, and returned task output/artifacts enter the normal evidence/verification loop. Settings → A2A provides discovery status, advertised skills, protocol/interface information, enable/disable controls, network scope, automatic context-sharing scope, per-skill approval policy, and connection testing.

A2A is local-first and privacy-aware: Community remains A2A-disabled, paid editions can enable it, Local Privacy Mode and managed network-deny policy stop discovery/delegation, task-only is the default automatic context scope, recognized credentials are redacted from delegated text, and full-context always requires exact one-time approval. Agent Card signature metadata is surfaced but is not yet cryptographically verified. Eymia 0.4.1 acts as an A2A client/delegator; it does not expose the workspace as an inbound A2A server.

Evidence-Grounded Cognitive Scaffold 0.4.0

Version 0.4.0 moves more investigation work into the Eymia host so smaller open models receive focused evidence rather than a long orchestration prompt. It adds model-aware scaffolding, explicit information-needs, query-aware context ranking, and first-class installed edition/version identity while preserving the 0.3.4 loop, tools, approvals, MCP, RAG, Multi Agent, rollback, recovery, and verification.

Smarter Reasoning and Understanding 0.3.4

Version 0.3.4 makes Eymia continuously validate that it is solving the right problem, not merely executing tools correctly. Every mode shares a versioned intent ledger, ambiguity-aware readiness gate, ranked next-action decision loop, explicit outcome/failure classification, and a completion guard that re-checks user-intent alignment. The original user request is never silently rewritten; Eymia's interpretation is allowed to evolve when evidence shows an assumption was wrong.

The release preserves the 0.3.3 Continue/Pause timeout recovery, edition-aware activation/upgrade guidance, VEX timeout handling, and user-facing next-action recommendations. Code mode is now labeled simply Code; legacy stored values continue to migrate safely.

Build Reliability and Dependency Security 0.3.2

Version 0.3.2 keeps the 0.3.1 production-hardening behavior and tightens reproducible local builds. It removes an unused dependency, explicitly reviews dependency install scripts, pins npm 11.16.0 in .npm-version, forces the public npm registry, and makes any npm audit advisory a release blocker. Use npm run release:build:all after configuring the paid-edition public key to validate and package the licensed editions.

Build Reliability and Dependency Security 0.3.1

Version 0.3.1 is a build-fix and dependency-security release on top of the 0.3.0 production-hardening work. It preserves the edition, licensing, skill-routing, VEX, safety, and recovery behavior while tightening the dependency and release pipeline that produces the VSIX files.

Security and reproducibility changes

• XLSX reading no longer depends on ExcelJS. Eymia uses a bounded, read-only JSZip parser and rejects oversized or unsafe worksheet parts instead of carrying the obsolete ExcelJS archive dependency chain.
• dependency:security:floor validates the exact lockfile before release and rejects known-vulnerable package floors or reintroduction of the removed ExcelJS/archiver/inflight/fstream chain.
• release:validate first runs the repository formatter and then verifies canonical formatting, so replacement-source delivery cannot fail the release solely because Prettier has not yet normalized the tree.
• VSCE 3.9.2, esbuild 0.28.1, and Prettier 3.9.4 are pinned in the release source. Expected packaging lifecycle scripts are recorded explicitly; optional keytar execution is not required for packaging.
• release:build:community now creates and verifies the root vscode-agent-platform.vsix, runs the VSIX install and extension-host smoke tests, generates release evidence, and performs the final readiness check.
• release:build:editions validates the source once and then creates edition artifacts under release-packages/; Community and Test do not require a license key, while paid editions require the external Ed25519 verification public key.

The authoritative build environment remains Node 24.18.0 and npm 11.16.0. For 0.3.2, a release is not certified until npm ci, npm audit --audit-level=info, npm run release:validate, and the packaged smoke/readiness checks all pass on that pinned environment.

Production Hardening 0.3.0

Version 0.3.0 turns Eymia's edition, skill, VEX, governance, and release concepts into runtime-enforced product behavior while preserving the evidence-driven recovery loop from the 0.2.x line. The release is designed around a simple rule: the host decides what is allowed, the model proposes how to help, and successful execution must be supported by evidence.

Enforced product editions

Eymia builds Community, Pro, Team, Education, Enterprise, and Enterprise On-Prem packages from one source tree. config/editions.json is the authoritative capability and limit matrix. Edition ceilings are enforced at command/UI exposure, backend and mode routing, workspace roots, skill libraries, tool registration, tool execution, MCP, indexing, rollback, process execution, and VEX access. Paid packages use offline Ed25519-signed license files; if activation is absent or invalid, the package safely exposes only Community entitlements.

Intelligent skill routing

• Skills may live in nested Markdown files and may include frontmatter metadata for intent triggers, modes, project types, file patterns, priority, and always-on behavior.
• Automatic routing selects only relevant skills for the current request and project evidence instead of injecting every enabled skill.
• Manual selection remains available, and prompt/library/selection limits are enforced by edition.
• Education can restrict the router to teacher-approved skills and use guided or explain-first assistance.

General production safeguards

• All VEX readiness/build actions use Eymia's normal workspace-trust, sandbox, exact-action approval, audit, and result-presentation path. Ordinary .vscode folders no longer create false VEX projects, and capability reports describe only operations Eymia actually implements.
• High-impact database, infrastructure, cloud, cluster, publish, container, Git-push, lockfile, generated-output, and similar actions require fresh one-time approval; binary and protected dependency paths cannot be treated as editable source text.
• Project analysis and test discovery recognize common polyglot and monorepo build systems and decline to invent a test command without repository evidence.
• A privacy-safe support bundle provides edition/runtime/tool/task-health diagnostics without prompts, file contents, workspace paths, backend URLs, API keys, credentials, or environment variables.
• Team, Education, Enterprise, and On-Prem packages can enforce managed backend/tool/mode/network policy and shared rules.

Release discipline

Production distribution must be built from the exact validated source using Node 24.18.0 and npm 11.16.0. Paid edition packaging additionally requires an Ed25519 public verification key through EYMIA_LICENSE_PUBLIC_KEY_FILE or EYMIA_LICENSE_PUBLIC_KEY; the private signing key must never enter the repository or VSIX. The VSIX-to-manifest verifier binds runtime bundle hashes, extension version, edition identity, feature/limit metadata, and the license public-key fingerprint.

Distribution model: Community is the Marketplace baseline. Pro, Team, Education, and Enterprise are licensed builds that retain the same extension identity so an edition replaces the existing Eymia installation rather than installing beside it. Enterprise On-Prem uses a separate private-distribution identity. Paid artifacts must be delivered through the licensed release channel together with a matching signed license; they are not separate public Marketplace listings.

Authoritative Recovery Runtime 0.2.11

Version 0.2.11 connects Eymia's recovery policies to the real execution runtime. Permanent host capabilities are tracked separately from the smaller tool set exposed for one observation, mutation, review, or schema-recovery step, so Eymia no longer confuses temporary safety gating with missing tools. Recovery state is isolated per task and workspace, repeated failed edits trigger a relevant evidence refresh, and cosmetic rewrites cannot masquerade as a new strategy.

Recovery that changes strategy instead of only blocking actions

• The adapter receives an authoritative host-tool inventory alongside the current step's allowed tools. User-facing capability warnings are based on the host inventory, while actual execution remains limited to the step-scoped set.
• A repeated failed mutation immediately requires current source or acceptance evidence. When a grounded work-product path exists, Eymia performs one deterministic read before asking the model for a different repair.
• Persisted recovery state is accepted only when its task, workspace, selected target, and objective match the active run. New runs begin with a fresh verification baseline.
• Python whole-file mutations are compared using conservative structure-aware normalization that ignores indentation width and blank lines but preserves behavior-changing text.
• Edit guidance prefers exact text copied from the current file and enough surrounding structure to keep inserted code inside the correct function, class, or block.
• Required source, documentation, configuration, and verification work remains tracked through completion. No benchmark identity or expected implementation is used by production recovery logic.

Evidence-Gated Human Recovery 0.2.10

Version 0.2.10 strengthens Eymia's general coding loop when an implementation has been executed but verification still fails. Recovery is now tied to the observed failure rather than to raw step count: unchanged results require fresh, relevant evidence before another edit, repeated hypotheses keep a bounded budget across resume and reload, and required supporting work remains visible until the task is actually complete.

Recovery that learns from evidence

• Common expected-versus-actual assertion output is converted into a compact behavioral contract without inventing a task-specific answer.
• An unchanged or regressed verification result activates an evidence gate. Mutation tools are withheld until Eymia inspects the current implementation or relevant acceptance evidence.
• Unrelated reads do not satisfy the gate. Evidence must touch the active work product, a required supporting deliverable, or a protected test, fixture, specification, or verification file.
• Tests and specifications remain read-only evidence unless the user explicitly asks to modify them.
• Repair and strategy-reset budgets are fingerprinted to the failure and persisted across pause, resume, reload, and extension restart.
• Source, documentation, configuration, and other required deliverables stay visible in the working prompt until all required work is complete.
• The primary chat coalesces repeated recovery and verification status into compact cards while detailed diagnostics remain available for inspection.

Local-Model Tool Protocol Recovery 0.2.9

Version 0.2.9 improves Eymia's ability to work with capable local coding models that sometimes produce the right action in the wrong function-call shape. Recovery is deliberately mechanical: Eymia may repair an unambiguous invocation envelope or mutually exclusive edit selectors, but it does not invent code, choose among ambiguous tools, or bypass normal safety gates.

More resilient execution without weakening safeguards

• A whole-response JSON argument object can be recovered only when exactly one currently available tool schema matches it and the user's prompt clearly requests execution.
• Ambiguous JSON, prose-embedded snippets, planning-only requests, and Architect-mode responses remain inert instead of being guessed into actions.
• Conflicting edit_file_range selectors are canonicalized only when an explicit mode or grounded current-file text makes the intended selector deterministic.
• Recovered file edits still pass candidate syntax/viability validation before approval; invalid code is rejected without modifying the workspace.
• Every recovered call still passes workspace trust, approval, sandbox, mutation-safety, rollback, evidence, and audit handling.
• safety-contract.json now contains SAFE-PROTOCOL-* acceptance claims so protocol recovery cannot silently become an execution bypass in a future release.

Operational Safety and Reliability Stabilization 0.2.8

Version 0.2.8 connected Eymia's expanded operational tools to shared network, privacy, targeting, and rollback controls. API/browser requests use bounded DNS-pinned transport, native VS Code actions preserve the triggering document/range, and persistent project knowledge participates in mutation safety rather than writing outside the transaction model.

Compatibility-Preserving Security Hardening 0.2.7

Version 0.2.7 strengthens process execution, MCP privacy, approval evidence, and release governance without removing supported Code workflows. The default shell mode remains compatible, structured execution stays available in every mode, and workflows that legitimately need credential agents or cloud profiles request named capabilities rather than inheriting the entire extension-host environment.

Safer execution without silent feature loss

• Every Eymia-owned child process now uses the same least-privilege environment builder. Project-specific environment variables can still be requested by name and bound to the exact approval without exposing their values.
• Ordinary platform and toolchain variables remain available, while ambient API tokens, passwords, cookies, connection strings, and credentials are excluded by default.
• SSH, Git, proxy, cloud, Kubernetes, container, and signing access is granted through named capabilities whose names and purpose appear in approval details; values remain hidden.
• run_process continues to use shell: false. Shell scripts and captured commands remain available in the default constrained mode, can be disabled for stricter deployments, and remain bounded by trust, approval, timeout, cancellation, output, and command-policy controls.
• Existing tool order and the default registry remain compatible when the new setting is left unchanged.

MCP data minimization and evidence

• Global MCP servers default to task-only metadata; workspace servers default to workspace-relative metadata.
• Absolute workspace and active-file paths are sent only when a server is explicitly configured for full-context.
• MCP approval details and results disclose the configured data scope.
• Receipt-backed structured assertions are attached to assistant presentation, while the existing truthfulness guard remains active as a fallback rather than being removed during migration.
• safety-contract.json links release claims to code and test identifiers, and CI validates child-process boundaries plus command registration consistency.

Human Recovery and Persistent Attempt Timeline 0.2.4

Version 0.2.4 improves how Eymia responds when a model proposes an invalid tool call and how live task evidence remains visible during longer conversations. A malformed action is rejected safely, then handled through a bounded schema-recovery lane that asks the selected model to correct the mechanical call shape without inventing missing code or claiming success. The Attempt Timeline is now a persistent task panel with independent scrolling, bottom-aware auto-scroll, and a new-event indicator when the user is reviewing older evidence.

Human-style malformed-action recovery

• Invalid tool input is treated as a recoverable mechanical mistake rather than immediate proof that the requested task is impossible.
• Eymia restricts the recovery turn to the rejected tool and supplies its actual required schema, grounded target, and rejection reason.
• A plan, explanation, or promise during schema recovery is classified as no progress and receives a stricter tool-only correction request.
• Recovery is bounded and persisted across pause or restart; repeated invalid calls still stop honestly rather than looping indefinitely.
• Eymia never fabricates missing mutation content. A corrected model proposal must pass the normal schema, approval, safety, readback, verification, and completion gates.

Persistent live task evidence

• The Attempt Timeline is docked outside the normal transcript so later chat messages do not push it out of view.
• The timeline has its own bounded scrollbar and does not change ordinary transcript scrolling.
• New events auto-scroll only while the user is already following the latest event.
• When the user scrolls upward, Eymia preserves that reading position and shows a compact new-event control that returns to the latest evidence.
• Completed and resumed tasks retain a stable task identity and a larger bounded event history.

Cross-Platform and Enterprise Hardening 0.2.3

Version 0.2.3 resolves Python launchers against the active execution host, requires strict SSH host-key verification by default, validates release documentation through a semantic contract, and moves TypeScript resolution to the Node16 compatibility path. Remote diagnostic routing and sidebar settings validation now live in focused modules rather than the main coordinators.

Verification State Reconciliation 0.2.1

Version 0.2.1 fixes a completion-truth defect that could leave an earlier failed verification active after a later repair passed. Eymia now reasons about verification like a careful engineer: failed attempts remain in history for learning, but only evidence applicable to the current workspace revision controls completion.

Current-state completion truth

• Every validated mutation advances a monotonic workspace evidence revision.
• Verification, runtime, visual, review, and manual receipts are bound to the workspace revision they actually observed.
• A newer receipt supersedes an older result only within the same logical proof stream; the old result remains available for audit and recovery.
• A mutation after a passing test invalidates that pass until the new workspace state is verified.
• Fail → repair → pass and repeated-failure → final-pass flows now complete correctly.
• Legacy acceptance-evidence state migrates into the revision-aware schema without inventing proof.
• Equivalent acceptance criteria collapse by stable semantic identity, while numerically different requirements remain distinct.
• Manual evidence is criterion-specific and cannot accidentally satisfy unrelated requirements.
• Completion, acceptance, kernel, and solution-evaluation failure messages are deduplicated into one actionable reason per underlying problem.
• Task History displays the current workspace evidence revision and latest acceptance receipt.

Modular Autonomous Engine 0.2.0

Version 0.2.0 introduces an event-driven task kernel around Eymia's proven Code execution loop. The model still proposes hypotheses, plans, code, and tools, but lifecycle transitions, tool authorization, acceptance evidence, verification diagnostics, review requirements, and completion are now represented as explicit host-managed state.

Event-driven autonomous execution

• TaskKernel records bounded lifecycle transitions for evidence gathering, planning, mutation, verification, repair, review, blocking, pause, failure, and completion.
• ToolExecutionCoordinator combines progressive tool policy with unified process, network, and mutation budgets without charging blocked preflight proposals.
• AcceptanceEvidenceMatrix maps every mandatory criterion to direct or explicitly labeled proxy evidence and fails closed when strict runtime, screenshot, or reviewer proof is unavailable.
• CompletionGate is the single completion authority. Mechanical validation, project verification, task-kernel invariants, required deliverables, acceptance evidence, independent review, and requested runtime behavior must agree before Eymia reports success.
• VerificationDiagnostics normalizes TypeScript, ESLint, pytest, Jest, Rust, Go, Java/Gradle, .NET, and generic compiler output into stable diagnostics that survive path, line, port, process, and timestamp changes.
• ReasoningStateV2 persists the task kernel and acceptance matrix alongside attempts, failures, verification comparisons, changed paths, strategy resets, and execution budgets.
• Task History now exposes the current kernel phase, next required action, blockers, verification state, acceptance counts, and recent state transitions.
• The 0.1.29 production loop remains the compatibility adapter during this staged extraction, preserving approvals, automatic pre-edit grounding, rollback, repair, MCP execution, and existing model routing.

Trustworthy Decision Kernel 0.1.29

Version 0.1.29 turns Eymia's evidence-driven human-quality reasoning from model guidance into host-enforced control. Code now uses typed intent resolution, progressive tool disclosure, deterministic mutation and verification gates, persisted reasoning state, untrusted-context provenance, unified side-effect accounting, acceptance-evidence checks, and DNS-pinned safe web requests.

Enforced evidence-driven execution

• The model proposes actions, but Eymia decides which action classes and tools are allowed from the current task state.
• Existing files are inspected before mutation when a read path is available; bounded mutation tools may self-ground through host validation, snapshots, and atomic target checks when no model-facing read tool exists.
• Edits cannot bypass verification requirements, repeated failed strategies are fingerprinted, and completion remains blocked when required acceptance evidence is missing.
• Reasoning state now survives task persistence, including evidence, attempts, failures, verification comparisons, changed paths, strategy resets, and execution-budget usage.
• Code recognizes natural change and execution requests instead of depending only on a small verb regex.
• Repository, tool, MCP, web, terminal, and model-generated content carry explicit trust labels so untrusted instructions cannot silently become task authority.
• Web fetching connects to an already validated public IP while preserving the original host and TLS server name, closing the validation-to-connection DNS-rebinding gap.
• Backend credentials are accepted only through VS Code SecretStorage; public Settings no longer expose API-key fields, and failed legacy migration never deletes the original credential.
• Shared agent-mode, execution-environment, MCP, and sidebar contracts now live in dependency-neutral modules; the release gate rejects future circular imports.
• Full replacement archives exclude stale VSIX, build-manifest, compiled-test, and release-validation artifacts so every branch rebuild begins from current source.

Target Identity Grounding and Read-Only Path Recovery 0.1.28

Version 0.1.28 improves how Eymia reacts when the task named in the request and the explicitly selected folder do not agree. Eymia now behaves like a careful human engineer: it gathers read-only evidence from the selected folder, surfaces the mismatch, and asks which target should be changed before permitting mutation.

Safe target mismatch handling

• A typed work-item identifier no longer disables selected-folder analysis merely because the folder contains a different identifier.
• Read-only project inspection still runs, so the model receives the real tree, source previews, tests, instructions, and verification evidence instead of inventing paths.
• Eymia records the conflict and requests focused clarification before writes or process execution. It never silently chooses one target over the other.
• When a model guesses that a root task or specification file lives inside a nested source directory, read tools may retry the same basename at the explicit selected-folder boundary. This recovery is read-only and never crosses into an unrelated work item.
• Command-shaped tool requests written as prose are treated as protocol failures and retried through the real tool interface, preserving approvals, sandboxing, rollback, and auditability.

Reproducible Release and Human Repair 0.1.27

Version 0.1.27 makes the release pipeline reproducible and strengthens evidence-driven recovery after a model produces an incorrect implementation.

Evidence-driven human repair

When executable verification fails, Eymia now treats actual-versus-expected output as a behavioral contract. It identifies every observed mismatch, asks the selected model to infer the smallest general rule across all failures, rejects repeated or cosmetic candidates, and grants a bounded additional repair opportunity before declaring a model stall. This logic is domain-neutral: it does not encode benchmark IDs, naming rules, or expected answers.

Transactional restart and public builds

Restart with Current Model no longer cancels the paused task first. Eymia starts and persists the replacement, links both task records, and only then marks the original as superseded. If submission or startup fails, the original task remains paused and resumable.

Release builds use the public npm registry, the exact Node 24.18.0 pin, VSIX-to-manifest hash verification, cross-platform ZIP creation that preserves hidden files, and generated RELEASE_VALIDATION.json / RELEASE_VALIDATION.md evidence.

Reproducible releases

• The release toolchain is pinned to Node 24.18.0 and npm 11.16.0 through .nvmrc, .node-version, strict release preflight, and packageManager.
• package.json is the single VSIX packaging allowlist. A root .vscodeignore is now a release-preflight conflict rather than a second competing packaging strategy.
• Generated dist-test output is never treated as source evidence and is excluded from full replacement archives. Stale VSIX and build-manifest artifacts are also omitted until regenerated from the current source.
• Cleanup and replacement packaging use cross-platform Node scripts rather than Unix-only rm -rf commands.
• npm run release:preflight, npm run settings:catalog:check, and npm run package:replacement provide deterministic release gates.

Clear task continuation

A paused task now presents two different actions:

• Resume Original continues the existing task with its original pinned model, checkpoints, task contract, and run identity.
• Restart with Current Model supersedes the paused run and creates a new task from the current composer backend and model selections.

The two actions are intentionally separate so changing the model in the composer never silently rewrites an existing task.

Shared project-analysis policy

A workspace-level .eymiaignore is now loaded by both indexing and analyze_project. Historical reports, generated output, packaged VSIX files, and other project-specific noise can therefore be excluded consistently from retrieval and project analysis.

Task-control, conditional task-control, specification, and verification filenames are configured through agentPlatform.taskArtifacts.*. The defaults preserve common conventions, but projects can replace them without adding benchmark- or repository-specific code to Eymia.

Settings detail and module boundaries

The Settings detail selector supports Essential, Advanced, and Expert disclosure. Its classification comes from the generated settings catalog in src/generated/settingsCatalog.ts, which is produced from package.json and documented in docs/SETTINGS_CATALOG.md.

Large coordinator responsibilities have begun moving into focused modules for utility lookup routing and formatting, task-artifact policy, ignore policy, and structured tool-result rendering. This is a behavior-preserving decomposition rather than a rewrite of the safety-critical execution loop.

Intent-to-Action Alignment 0.1.25

Eymia now distinguishes the work product that owns the requested behavior from files that only describe or evaluate the task. For implementation work it builds a pinned map of primary targets, required supporting deliverables, acceptance evidence, and protected control files before asking the model to act.

The recovery path follows a human engineering pattern:

1. identify the requested outcome and the artifact responsible for it;
2. use tests, specifications, instructions, and verification scripts as evidence rather than editing them by default;
3. reject a wrong-file action with a concrete explanation and corrected target;
4. execute one real change, read back the resulting state, and verify it;
5. keep going when an explicit supporting deliverable such as documentation or configuration remains incomplete;
6. stop early when the model repeats the same target misunderstanding instead of spending the full step budget.

Explicit requests to maintain instruction, specification, test, or verification files remain allowed. Tool approval, sandboxing, rollback, and truthfulness controls are unchanged.

Host-Aware Investigation 0.1.24

Eymia now treats where a tool runs as part of the tool contract. Before answering questions about a computer, connected hardware, processes, storage, network interfaces, or installed software, it can identify the active VS Code extension host and choose fixed read-only probes for macOS, Linux, or Windows. Remote MCP acknowledgments no longer count as proof that a local observation happened.

The investigation path is generic:

1. resolve the requested target and execution host;
2. select an observation method compatible with that host and operating system;
3. collect broad evidence;
4. narrow it using the user's subject;
5. report only what the returned evidence supports;
6. change the host, tool, or hypothesis when an attempt returns no new evidence.

run_shell_script also supports explicit shell selection (sh, bash, zsh, cmd, powershell, or pwsh) while continuing to use the shells installed on the host.

Offline-first, MCP-native, multi-backend editing assistance for VS Code with support for local or remote model endpoints.

After Install: 2-Minute Quick Start

If you just installed this addon and want to confirm what it is and how to use it fast:

1. Open Get Started in VS Code and run the walkthrough: Eymia AI Offline Editor: Welcome.
2. Open the Eymia sidebar from the Activity Bar.
3. Run Eymia AI Offline Editor: Select Backend.
4. Run Eymia AI Offline Editor: Test Backend Connection.
5. Start a Code or Review task with a read-only prompt like:

• "Explain this function"
• "Review this module for likely TypeScript errors"
• "Explain how these tests cover this class"
• "Summarize the architecture of this workspace"

What you installed:

• Eymia AI Community is an offline-first coding assistant extension.
• The Community beta supports local models and read-only developer assistance.
• File mutation, process execution, remote backends, MCP, and multi-agent workflows require another edition.

Settings Model Classification 0.1.23

The Settings model pickers now classify the model currently selected in the unsaved backend draft. Every Primary, Multi Agent editor, planner, reviewer, and embedding choice is grouped by Ready, Caution, or Blocked suitability and shows its model family, capabilities, confidence, installation state, and role-specific explanation.

Classification updates as soon as the selection changes; pressing Save is not required to see the result. Primary Model is evaluated for the active single-model mode, while Multi Agent roles are evaluated independently. Classification remains advisory: it does not replace the selected model or enable automatic model switching outside Multi Agent mode.

State Coordination and Product Stabilization 0.1.22

Eymia now starts every task from one immutable composer snapshot containing the prompt, mode, backend, selected model roles, conversation, selected folder, attachment, and UI revision. Code, Architect, Autonomous, and Review enforce the submitted primary model for the full run. Multi Agent remains the only mode that can intentionally route planner, editor, and reviewer roles to different models.

The sidebar uses a real run lease instead of a fixed busy timeout. A run owns a stable ID, heartbeat, cancellation state, and possibly-stalled status, and the composer unlocks only after a terminal result. Streaming tokens patch the active assistant entry on a short throttle rather than rebuilding the entire application for every token, and the old periodic full-state refresh has been removed.

Execution now begins with a pinned task contract and records a causal attempt timeline: hypothesis, proposed action, approval, actual result, resulting state, verification, and decision. Live task cards expose the requested outcome, mandatory criteria, verification requirements, prohibited changes, unresolved questions, and latest solution evaluation. Conversation evidence carries provenance, confidence, timestamps, expiry, and invalidation data. Multi Agent reviewers receive an independent evidence packet rather than relying on the editor's confidence or explanation.

Workspace indexing updates only changed or deleted files. Web requests validate DNS results and every redirect against private and reserved address ranges. Sidebar commands use an extension-host allowlist rather than command URIs. Production packaging uses a strict runtime allowlist, does not activate globally at startup, and lazy-loads document and syntax-highlighting engines. The main activation bundle is approximately 0.8 MB, with release budgets preventing accidental regressions.

Operating Modes

• Code: uses the single model selected in the composer for inspection, editing, repair, and completion. Planner/editor settings do not switch the model in this mode.
• Multi Agent: uses the selected planner model to produce a grounded handoff, then the selected editor model to implement and verify it. The composer displays both model selectors.
• Architect: creates a reviewable implementation plan before execution.
• Autonomous: performs a longer controlled task loop with autonomous limits and approvals.
• Review: provides read-only analysis of code and changes.

The execution-mode registry intentionally contains only these five modes. Legacy saved chat, edit, and guided-agent values are migrated to Code and are not available as runtime modes. Single-model modes use the composer-selected Primary Model throughout the task; planner/editor model settings are exclusive to Multi Agent.

Internal structured tool calls are executed by Eymia and rendered as user-facing tool cards; raw tool-call JSON is reserved for diagnostic exports and is not shown as a normal assistant message.

Provider Profiles and API Keys

The backend selector saves immediately when a provider is selected. Each provider has an independent profile for its endpoint, context window, primary/editor/planner/embedding models, and API key. Switching to another provider does not clear the profile you were editing.

API keys are stored per provider in VS Code SecretStorage rather than plain settings. During the current sidebar session, switching away and back preserves the password field. After VS Code reloads, Eymia shows a masked stored state instead of re-exposing the secret value.

Human Reasoning and Solution Evaluation 0.1.19

Eymia now applies one orchestrator-owned decision frame across tools, modes, memory, mutation safety, recovery, and verification. Before implementation, it evaluates whether the objective, workspace target, current evidence, capabilities, user boundary, evaluation path, and rollback path are sufficient. Existing files must be observed in the current run before their first mutation; when possible, Eymia performs the safe read automatically instead of blindly editing or wasting another model turn.

Conversation state now preserves bounded lessons about failed actions, approval or policy constraints, important orchestrator decisions, and successful verified outcomes. These records survive model changes and context compaction, while remaining separate from untrusted assistant narration. A later success can resolve an earlier failure lesson, and repeated failures increment one fingerprinted record instead of creating noisy memory.

Final implementation quality is evaluated across scope alignment, mutation readback and local validation, project verification, independent reviewer evidence when configured, and explicitly requested runtime behavior. Eymia exposes a weighted score for clarity but remains fail-closed: missing mandatory evidence blocks a verified-success result. See docs/HUMAN_REASONING_LOOP.md for the full architecture.

Approval Menu and Containment 0.1.18

Approval actions now remain compact instead of stretching across the full approval card. Allow Once, the approval-scope arrow, and Skip stay visible together and wrap only when the sidebar becomes extremely narrow.

The approval-scope menu now expands inline inside the card. This avoids the previous clipping failure where the arrow changed state but the remembered choices were rendered outside an overflow-hidden popup. The control exposes an accessible label and synchronized expanded state.

Long paths, task names, commands, scope explanations, and model-run identifiers are constrained to the transcript width. The transcript itself no longer acquires a horizontal scrollbar from an approval card; only dedicated command and code surfaces may scroll horizontally when preserving exact text is useful.

Action Viability and Recovery Integrity 0.1.17

Eymia now proves that a proposed mutation is meaningful and executable before asking the user to approve it. File edits, full writes, creates, moves, deletes, and patch bundles are evaluated against the current workspace, and the exact predicted effect is pinned to the state that was inspected.

edit_file_range has three explicit, mutually exclusive modes: exact-text, range, and whole-file. Exact-text edits can select one occurrence or intentionally replace all matches. Range edits are constrained to the supplied lines and never fall back to a global text search. Whole-file edits are atomic and intended for deliberate complete rewrites. Legacy model calls are normalized into one of these modes only when the intent is unambiguous.

Before approval, Eymia rejects identical replacements, whitespace-only evasions, conflicting selectors, ambiguous matches, invalid ranges, stale hashes, unsafe targets, and candidate content that fails supported syntax checks. Viable actions receive file or path-state fingerprints. If the workspace changes while an approval card is open, execution stops and the stale candidate is discarded rather than modifying newer content.

Tool failures are routed through a deterministic Recovery Director. It produces a concise user message and a bounded model packet describing the failure category, current target, rejected strategy, and required mechanical alternative. Failed and preflight-rejected actions receive no progress credit, and semantic duplicate detection blocks repeated strategies even when their JSON or whitespace differs. Internal stall codes remain in diagnostics instead of appearing as normal assistant messages.

The same pre-approval executor and recovery services are shared by every mode. Code and Autonomous may execute viable approved mutations, Multi Agent preflights editor proposals before approval and gives reviewers only actual evidence, Architect remains planning-only until implementation is authorized, and Review remains read-only.

Multi-Turn State and Action Integrity 0.1.15

Eymia no longer relies on transcript prose alone to remember what a user means across turns. Each conversation owns a local, versioned working-state graph containing stable handles for files, repositories, branches, background processes, terminals, remote hosts, databases, containers, Kubernetes contexts, debugger and browser sessions, MCP resources, documents, and external services.

Resources carry explicit states such as remembered, pending approval, active, stale, closed, and failed. Remembering user@host is therefore not the same as proving an SSH connection, and starting a process is not considered successful until a receipt confirms execution. Follow-up requests such as “show its logs,” “stop it,” or “what space is available?” resolve against compatible verified resources. When multiple targets are plausible, Eymia asks rather than guessing.

Successful tool calls produce durable evidence receipts linked to the resources they established. Before a normal assistant message is shown, a truthfulness gate checks claims about connections, commands, edits, deployments, and verification against those receipts. A later mutation invalidates an older “tests passed” claim until verification runs again. Unrequested tool JSON, adapter envelopes, and internal context records are converted to readable messages instead of appearing in chat.

The state belongs to Eymia rather than the selected model. It survives provider and model changes, context compaction, sidebar refreshes, and extension restarts. Models receive a bounded, redacted context packet describing current resources and user boundaries, not an untrusted narrative reconstruction. Planning-only, workspace-mutation, and process-execution restrictions are tracked separately, so “implement this, but do not run tests” remains logically enforceable.

The sidebar shows active-resource chips with their real status. Clear removes remembered conversation context only; it does not undo workspace changes or claim to terminate external processes. Resource state and exports are sanitized before persistence, and API keys, tokens, credentials, authorization values, private keys, and similar secret fields are excluded.

Tool Platform 0.1.14

Eymia now resolves every built-in and MCP tool through a shared Tool Contract v2. Contracts declare effects, risk, reversibility, output capture, supported modes, dependencies, timeouts, presenters, and execution profiles. Before execution, the request is normalized into one exact action used consistently by sandbox checks, approval, audit, duplicate detection, and user-facing tool cards.

Permissions are action-scoped rather than tool-wide. Users can allow once, for the current task, for the current session, or for one matching action in the workspace, and can save an exact deny rule. MCP and built-in tools share the same inline approval experience. Execution profiles remain independent from approval: read-only, workspace-write, network-restricted, isolated-task policy, and full-access. The isolated-task profile is a policy boundary in this release; OS/container or worktree isolation remains a 0.2.0 expansion.

The process layer now includes structured captured execution, explicit shell scripts, visible interactive terminals, background-process start/read/list/wait/stop operations, cancellation, timeout and output limits, redacted environments, port checks, and execution receipts. Tasks that require Eymia to inspect output are kept on capturing tools.

All five modes have persisted typed phase histories. Multi Agent adds a compact planner/editor/reviewer configuration popover, provider-specific reviewer defaults, immutable role routing, and a real read-only reviewer stage with typed pass/fail evidence and bounded repair handoff. Model-role activity is shown ephemerally and disappears when real output begins.

Tool input passes through staged recovery for aliases, JSON strings, missing optional fields, safe scalar coercion, schema validation, and semantic preflight. Dangerous ambiguity is never guessed. Internal protocol and raw JSON remain diagnostic data and are not rendered as normal assistant messages.

Senior Engineer Execution Loop

Every mutating task is controlled by a deterministic engineering loop around the selected model:

1. resolve the workspace, task boundaries, selected mode, and selected model before model execution;
2. gather a bounded evidence packet from relevant files, tests, instructions, and prior failures;
3. require a grounded diagnosis and executable strategy rather than planning-only narration;
4. snapshot each target before mutation and keep one cumulative rollback change set;
5. read changed files back and run language-aware local validation immediately;
6. restore the last valid state automatically when a mutation is unreadable or syntactically invalid;
7. run verification in layers and fingerprint failures as improved, repeated, or regressed;
8. score real progress, reset the strategy after repeated failures, and reject identical/no-op repairs;
9. complete only after a deterministic senior review gate confirms bounded scope, valid changed files, and passed required verification.

The model proposes code and diagnoses. Eymia owns workspace boundaries, evidence, rollback, validation, progress decisions, verification, and completion.

Current State

This repository currently contains:

• a product and architecture scaffold based on the build specification
• a TypeScript VS Code extension shell
• core contracts for agents, tools, orchestration, safety, MCP, patching, audit, and persistence
• a minimal sidebar experience and command surface
• model connectivity for Ollama, llama.cpp, Hugging Face local servers, the hosted Hugging Face Router, LM Studio, NVIDIA NIM, and custom OpenAI-compatible APIs
• MCP runtime coverage for HTTP, stdio, and websocket transports with live tools/list probing
• patch review, apply, rollback, and rollback-history surfaces
• .eymiaignore support for excluding local files from workspace indexing
• default secret-file exclusion from workspace indexing for .env, credential, key, certificate, and common token files
• deterministic tool-first handling for simple create/write-file tasks, including verification after writes
• model suitability checks that stop guardian, safety, embedding, classifier, or vision-only models from running coding-agent edit workflows
• sidebar configuration update whitelisting and safer workspace-only path opening
• built-in agent profile loading from agent-profiles/ in source and packaged layouts
• eymia.rules.md support for repo-level assistant guidance
• conversation export, release notes, support/contact, and about/version commands
• local privacy mode that disables built-in web search/fetch tools by default
• immutable per-task and per-conversation model routing with visible planner/editor readiness and resume-safe task snapshots
• persistent per-provider backend profiles: provider selection saves immediately, API keys remain isolated in VS Code SecretStorage, and switching providers preserves each provider's URL, model, context, and credential state
• persistent conversation working state with typed resource handles, evidence-backed execution claims, safe follow-up reference resolution, stale-state detection, and active-resource status chips
• automated unit and integration-style coverage across core orchestration, patching, approvals, and MCP logic

Some settings and contribution points are intentionally forward-looking. Inline completion, richer RAG workflows, deeper MCP payload normalization, and image-heavy workflows should be treated as experimental unless the command or sidebar surface explicitly exposes and validates the workflow.

See docs/CAPABILITY_MATRIX.md for the current stable versus experimental feature breakdown.

For a knowledge-management-friendly product overview, import docs/KNOWLEDGE_BASE.md.

Deterministic Multi-Model Routing

Eymia snapshots model routing at task start. Code, Architect, Autonomous, and Review use the conversation's selected primary model for the complete task. Multi Agent snapshots separate planner and editor models and preserves that route across pause, resume, context compaction, and workspace-setting changes.

Model choices are conversation-local, so separate chats can keep different model combinations without rewriting workspace defaults. The composer shows role-aware readiness for the selected models, and live task cards display the exact pinned route and its source. Unknown model families remain usable but are labeled as estimated rather than silently assumed compatible.

Model changes are recorded as transcript events. The role-readiness card appears immediately after a model selection and automatically collapses when the user starts typing, returning the prompt composer to its compact two-row layout.

Baseline-Aware Recovery

Eymia validates likely target source files before the first mutation and distinguishes the current task baseline from a last-known-valid snapshot. When an attempted edit is syntactically invalid, Eymia restores the safest available state, rereads the actual file, invalidates stale edit assumptions, and gives the selected model a materially different strategy opportunity before declaring a stall.

The recovery controller is project-evidence driven. It does not contain benchmark task answers or task-specific repair recipes. Direct conversation-export requests are handled locally with typo tolerance, and explicit user cancellation is reported as cancellation rather than an Ollama failure.

Auto Compact

Auto Compact is enabled by default so long conversations and long-running coding tasks do not keep feeding the model an ever-growing stream of repetitive history. It works locally and deterministically; compaction does not require a second model request.

Two layers are compacted independently:

• Conversation memory: older user goals, decisions, file references, errors, and verified outcomes are condensed into durable structured memory while recent messages remain verbatim.
• Live agent checkpoints: oversized step-by-step tool history is condensed before the next model turn while the most recent checkpoint notes remain unchanged.

Default settings:

• agentPlatform.context.autoCompact.enabled = true
• agentPlatform.context.autoCompact.triggerPercent = 45
• agentPlatform.context.autoCompact.keepRecentEntries = 6
• agentPlatform.context.autoCompact.targetTokens = 1200

The sidebar context meter includes conversation-memory usage and reports the current Auto Compact state and revision. Compaction also triggers before the persisted conversation reaches its normal entry cap, preventing useful older context from being discarded without a memory summary.

Privacy

Eymia AI Offline Editor is designed as an offline-first VS Code extension. It does not collect, store, sell, or share personal data with Eymia, and it does not transmit workspace files, source code, prompts, API keys, editor activity, or usage telemetry to any server operated by Eymia.

See the repository PRIVACY.md file for the full policy. For privacy questions, contact support@eymia.com.

License

The source tree defaults to the Eymia Community License v2.0. Community is free for personal projects, learning, evaluation, non-commercial open-source work, and individual educational use. Commercial development and managed organizational use require the applicable paid edition or written agreement.

Edition packaging installs the appropriate license notice automatically. Pro, Team, Education, Enterprise, and Enterprise On-Prem packages also require a matching offline Ed25519-signed license file. See licenses/ and business/EYMIA_LOCAL_AI_WORKBENCH_PRICING.md.

Getting Started

1. Install dependencies with npm install
2. Build with npm run build
3. Open the repository in VS Code
4. Press F5 to launch the extension development host

Package The Extension

Use the canonical release command instead of pasting independent shell commands. It stops on the first failed gate and records the failure in release evidence.

1. Confirm node --version prints v24.18.0. If it already does, nvm is not required for that shell.
2. Install the locked dependencies with npm ci.
3. Apply the repository formatter once with npm run format, then review the resulting diff.
4. Run the complete release pipeline with npm run release:check. This performs architecture, formatting, lint, tests, audit, TypeScript compatibility, performance, packaging, npm run package:size, VSIX smoke, and semantic release-readiness checks.
5. Install the generated Community vscode-agent-platform.vsix in VS Code with Extensions: Install from VSIX....
6. For the public Community beta, run npm run release:build:community:beta. This produces and validates the pre-release artifact under release-packages/.
7. For the license-free artifacts, run npm run package:editions. This always writes Community and Test VSIX files, then skips paid editions if no public key is configured.
8. For paid edition artifacts, provide the production Ed25519 public verification key through EYMIA_LICENSE_PUBLIC_KEY_FILE (recommended) or EYMIA_LICENSE_PUBLIC_KEY, then run npm run package:editions or npm run release:build:all. Never place the private signing key in the repository.
9. Use npm run license:issue -- --edition <edition> --license-id <id> --subject <name> --private-key <private-key.pem> --out <license.json> from a secured signing environment to issue paid licenses.
10. Use RELEASE_QA_CHECKLIST.md for the final clean-profile install and edition-gating pass.

npm run package:extension performs a TypeScript check before packaging, so it cannot produce a new Community VSIX from type-invalid source. npm run package:editions packages Community and Test without a key. Paid package builds still fail closed for explicit paid edition commands when no verification public key is provided.

Build Paid Editions

The paid VSIX packages embed only the Ed25519 public verification key fingerprint and public key. The private signing key is used only in the secured license-issuing environment and must not be committed, copied into the release source, or embedded in a VSIX.

Recommended file-based setup on macOS/Linux:

export EYMIA_LICENSE_PUBLIC_KEY_FILE="$HOME/secure/eymia-license-public-key.pem"
npm run release:build:all

Inline setup is also supported when your shell history and CI secret handling are appropriate:

export EYMIA_LICENSE_PUBLIC_KEY="$(cat "$HOME/secure/eymia-license-public-key.pem")"
npm run release:build:all

PowerShell example:

$env:EYMIA_LICENSE_PUBLIC_KEY_FILE = "$HOME\secure\eymia-license-public-key.pem"
npm run release:build:all

With either public-key setting present, npm run package:editions and npm run release:build:all build Community, Test, Pro, Team, Education, Enterprise, and Enterprise On-Prem artifacts under release-packages/. Without the setting, they build only Community and Test and skip the paid packages.

Initial Commands

• Eymia AI Offline Editor: Explain Selection
• Eymia AI Offline Editor: Refactor Selection
• Eymia AI Offline Editor: Fix Selection
• Eymia AI Offline Editor: Generate Tests for File
• Eymia AI Offline Editor: Start Agent Task
• Eymia AI Offline Editor: Start Autonomous Task
• Eymia AI Offline Editor: About
• Eymia AI Offline Editor: Open Release Notes
• Eymia AI Offline Editor: Contact Support
• Eymia AI Offline Editor: Export Conversations
• Eymia AI Offline Editor: Export Privacy-Safe Support Bundle
• Eymia AI Offline Editor: Show License Status
• Eymia AI Offline Editor: Install or Replace License
• Eymia AI Offline Editor: Show Patch Preview
• Eymia AI Offline Editor: Show Rollback History
• Eymia AI Offline Editor: Open MCP Servers
• Eymia AI Offline Editor: Test MCP Connections
• Eymia AI Offline Editor: Select Backend
• Eymia AI Offline Editor: Test Backend Connection
• Eymia AI Offline Editor: Show Startup Status

Remote Explorer (SSH / WSL / Dev Containers)

SSH host-key verification

Eymia-managed remote diagnostics use strict known_hosts verification by default. An unseen or changed host key is rejected until its fingerprint is verified through a trusted channel. accept-new is available as an explicit trust-on-first-use convenience setting; it is never the silent default.

Eymia is configured to run as a workspace extension host, so when you connect with VS Code Remote Explorer it runs on the remote side with your project files and terminals.

Important routing behavior in remote sessions:

• localhost and 127.0.0.1 refer to the remote machine, not your laptop.
• Keep backend URLs like http://127.0.0.1:11434 only when the model server is on the remote machine.
• If the model server is on your laptop, use SSH port forwarding and target the forwarded port from the remote host.
• If the model server is on a third machine, use a host/IP reachable from the remote machine.

MCP in remote sessions:

• stdio MCP servers execute on the remote machine, so command paths must exist there.
• HTTP/WebSocket MCP servers must be reachable from the remote machine network.

Use Eymia AI Offline Editor: Run Doctor after connecting remotely to validate backend and MCP routing assumptions.

Remote SSH safety profile:

• agentPlatform.safety.remoteSshProfile = diagnostics (default): allows key-based ssh user@host and common remote diagnostics commands such as df, free, uptime, uname, and lsblk.
• agentPlatform.safety.remoteSshProfile = any-key-based: allows broader key-based SSH command usage.
• agentPlatform.safety.remoteSshProfile = deny: blocks SSH/SCP/SFTP terminal commands.

Secure remote diagnostic flow:

• Use the built-in run_remote_diagnostic tool to execute allowlisted remote diagnostics (disk-size, memory, uptime, and others), capture stdout/stderr, and present the result to the user.
• When no Eymia credential is selected, the tool uses the existing system SSH agent, SSH config, and key-based authentication with non-interactive BatchMode. This supports hosts that already work with commands such as ssh user@host.
• Run Eymia AI Offline Editor: Configure Remote Credential only when the connection requires a password or a private key that is not already available through the system SSH configuration. Credentials remain in VS Code SecretStorage.
• Requests that ask Eymia to check, inspect, list, or report command output are routed to a capturing tool rather than the visible terminal. Interactive terminal commands continue to use the visible terminal path.
• Remote diagnostics are high-risk actions. Eymia displays Command Requested, then asks for approval with the exact resolved SSH command before execution. The command is skipped only when the user previously chose Always Allow In Workspace for run_remote_diagnostic.
• Optional remote fields that were not supplied are omitted before schema validation, so a missing SSH port no longer blocks the approval prompt.
• After approval, the result card states whether execution occurred and includes captured stdout, stderr, exit code, duration, and authentication source. A failed or denied deterministic SSH request is not retried through the model.

Next Milestones

• manually QA deterministic simple-file creation in a packaged VSIX with several local coding models
• audit MCP stdio server startup approvals and permission escalation behavior in real workspaces
• improve the experimental downloaded VS Code extension-host runner
• graduate inline completion and richer RAG workflows from settings-level support to validated user workflows

Improvement Backlog

• continue splitting sidebar behavior into focused modules and reduce provider complexity further
• unify settings handling so runtime services and the sidebar share a cleaner configuration surface
• add a first-class model capability registry instead of relying only on heuristic suitability checks
• polish the sidebar UX after the code is easier to change safely
• expand the tool surface so the assistant can operate more effectively as a day-to-day coding companion

Verification Profiles

The autonomous verification loop can be customized per repository with .eymia/verification.json.

Example:

{
  "rules": [
    {
      "patterns": ["src/**/*.ts"],
      "toolName": "run_command_capture",
      "command": "npm run test:unit -- {changedPath}"
    },
    {
      "patterns": ["test/**/*.ts"],
      "toolName": "run_tests",
      "target": "{changedPath}"
    }
  ],
  "fallback": {
    "toolName": "run_tests",
    "target": "{changedPath}"
  }
}

Notes:

• rules are checked in order and the first match wins
• supported tools are run_tests and run_command_capture
• {changedPath} is replaced with the changed workspace-relative file path
• if no config is present, or no rule matches, the built-in verification heuristics still apply
• the selected rule or heuristic is shown in the sidebar activity stream during automatic verification

Agent Profiles

Eymia can build its system prompt from a workspace markdown template using agentPlatform.chat.agentProfilePath.

Included examples:

• agent-profiles/eymia-agent.md: balanced default Eymia coding profile
• agent-profiles/eymia-claude.md: a more terse, execution-focused Eymia profile
• agent-profiles/gpt-5.4.md: frontier-style coding profile for stronger reasoning models

You can switch profiles from the sidebar settings by changing Agent Profile, or by setting:

{
  "agentPlatform.chat.agentProfilePath": "agent-profiles/eymia-claude.md"
}

Known Limitations

• Eymia does not claim universal support for every programming language, build system, hardware target, cloud API, database, or external tool. It discovers supported capabilities from repository and tool evidence and should decline to invent commands when evidence is missing.
• VEX support in 0.3.0 is a safe development foundation: project/readiness detection and PROS build/clean build are implemented. Upload, run, stop, firmware management, serial sessions, and device-management operations remain unavailable until they are implemented through the same trust/approval/audit path.
• Managed Team/Education/Enterprise policy is local/workspace policy enforcement. Central fleet administration, remote license-seat accounting, and a hosted organization control plane require the separate Eymia enterprise platform/services.
• Offline paid-license validation verifies authenticity, edition, and expiration but does not itself provide online concurrent-seat enforcement. Seat scope remains a commercial/customer-agreement concern unless an enterprise control plane is connected.
• Database, browser, debugger, container, Kubernetes, and other external-resource continuity depends on built-in or MCP tools returning stable identifiers. Eymia cannot manufacture lifecycle operations a connected tool does not expose.
• Resource freshness remains evidence-driven. Consequential use of external resources should be revalidated because a host, cluster, database, or service may have changed outside Eymia.
• npm run test:integration covers extension activation/command wiring with a mocked VS Code host; packaged VSIX smoke tests and a final clean-profile manual pass remain required before distribution.
• The production orchestrator is intentionally being decomposed incrementally rather than rewritten wholesale. Safety-critical behavior stays behind existing task-kernel, tool-execution, verification, no-progress, and completion gates while focused modules continue to replace oversized coordinator responsibilities.