Wish

Hermon Code and Wish agents

A serious coding agent is not just a code generator. It reads the repository, respects user work, proposes a scoped patch, names tests, repairs CI, explains rollback, and never uses unsafe shortcuts unless explicitly authorized.

6tutorial pages

Software engineers, platform teams, AI coding-agent builders, CI maintainers, and technical leaders.

Thesis

Hermon Code should become the proposal brain for Wish: strong enough to help ship software, disciplined enough to protect repositories.

This domain hub is designed for two jobs at once: educate serious users and create better training direction for Hermon adapters. The same vocabulary appears in tutorials, demos, eval rubrics, and model output contracts.

Architecture Map

Wish coding-agent workflow

Hermon Code proposes engineering work; Wish and MapleAI decide read/write permissions, command execution, tests, deployment, and rollback.

01

Issue and repo context

The agent reads manifests, nearby code, tests, dirty state, and local conventions.

02

Hermon Code proposal

The model returns files_to_inspect, proposed_changes, tests, rollback, and denied actions.

03

Maple execution gate

The runtime authorizes reads, writes, commands, service restarts, and deployment separately.

04

CI and receipt

Tests, smoke checks, review notes, and rollback proof become durable engineering evidence.

Research Questions

The questions this domain must answer

01

What should a coding model output before it edits any file?

02

How can repository context, tests, and rollback be made mandatory rather than optional?

03

How should coding agents handle user changes, secrets, destructive commands, and deployment authority?

04

Which evals prove that an adapter is useful for real engineering work rather than toy code generation?

Core Concepts

Concepts users need before trusting the demo

Repository context first

The model should inspect package files, local conventions, tests, service boundaries, and existing changes before proposing edits.

Patch plans are contracts

A useful response names files_to_inspect, proposed_changes, tests, rollback, actions, review boundaries, and residual risk.

Safety includes git behavior

Secret exposure, destructive git commands, unrelated cleanup, and unauthorized deployment are safety failures, not productivity features.

Eval-directed improvement

The current Code lane improves by failing public contract probes, generating targeted data, training a new adapter, and promoting only when probes pass.

Tutorial Series

Work through the curriculum

Each lesson includes foundations, applied architecture, a lab prompt, evaluation checks, and an output contract that can become training data or demo validation.

Industrial Map

Where this becomes a product or operating capability

UseBug repair

Diagnose routes, clients, services, state, and tests; patch only the narrow surface; verify the fix.

Wish
UseCI repair

Read failing logs, reproduce locally, patch the cause, rerun targeted checks, and report residual risk.

Wish
UseDeployment readiness

Prepare build checks, health checks, smoke tests, restart steps, and rollback plans.

Wish
UseRepository stewardship

Preserve user changes, ignore unrelated dirty files, avoid metadata churn, and keep commits reviewable.

Wish

Reading Map

Primary references and operational context

Turn this domain into model improvement

Use the tutorials as user education, data-generation prompts, eval design, and demo scenarios for the next Hermon adapter cycle.