Mino Chapter Roadmap

This tutorial builds a terminal agent from scratch in Go using the OpenAI Responses API. The official OpenAI Go SDK handles API communication; Mino implements the interaction flow and the Agent loop introduced in Chapter 03. Each chapter follows one interaction: what the model receives, what the program does with the response, and how control or context reaches the next step. Getting started covers installation and API settings.

Chapters 01–15 are released, with code, bilingual lessons, and verification. The latest released chapter, Chapter 15, is available in chapter-15, application version 0.15.0, released 2026-10-29. The ten-chapter plan replaced an earlier nine-chapter numbering on 2026-10-21, and chapter-10 was republished on 2026-10-26 with permission modes; see republished releases.

Chapter	Status	Title	Question it answers
01	Released	Your first terminal conversation	How does one line of input become a streaming Responses request and an answer, and why do independent requests have no memory? Release chapter-01 (version 0.1.0).
02	Released	Keep a conversation going with JSONL history	Which saved records survive a restart and return to the model as context, and what happens to an incomplete final record? One conversation is kept as a session file under ~/.mino/sessions/. Release chapter-02 (version 0.2.0).
03	Released	The first Agent loop with tools and Bash	How does a tool call become an approved, bounded Bash execution whose paired result returns to the model? Each step is saved before the next, so a restart never reruns a command; only completed turns return as context. Release chapter-03 (version 0.3.0).
04	Released	Recover interrupted tool turns honestly	When a command may have run but its result was never saved, how does the model learn about it? Failed, cancelled, or interrupted tool turns are replayed with their paired results and a runtime notice, nothing is retried, and you must acknowledge an unknown result before chat continues. Release chapter-04 (version 0.4.0).
05	Released	Managing multiple conversations with JSONL sessions	How do you choose which conversation supplies context, keep others isolated, and clear one deliberately? The conversation from earlier chapters is selected in place. Release chapter-05 (version 0.5.0).
06	Released	Context compaction with manual and automatic triggers	How do /compact and automatic checks before each request keep context within budget while preserving recent turns and original history? Release chapter-06 (version 0.6.0).
07	Released	Skills for on-demand task knowledge	How does a fixed per-session catalog of project skills let the model request full task guidance with skill_view only when needed? Release chapter-07 (version 0.7.0).
08	Released	Read and write project files with file tools	How can structured read_file, write_file, and edit_file tools give the model precise project-file access that the program can actually confine? Paths resolve inside the startup project directory with os.Root; symbolic links, special files, and multiple hard links are refused. Reads are marked read-only like skill_view; each write or edit requires separate default-deny approval after a live inspection shows a bounded preview, and approval is bound to the inspected file content. Bash keeps its existing approval. Release chapter-08 (version 0.8.0).
09	Released	Connect external tools with MCP	How does a tool hosted by another process join the same Agent loop? Support remote Streamable HTTP servers such as Context7 and local stdio servers, using the MCP tools capability. mino mcp add, list, and remove manage a private ~/.mino/mcp.json, never project configuration; static request headers such as an API key are entered hidden and never reach the model, logs, or confirmations. Remote URLs require HTTPS. Approve each tool call (default deny), showing where its arguments will be sent; map tools to unique local names, convert schemas to Responses tools, and treat descriptions and results as untrusted external content. Timeouts and disconnects after a call is sent become unknown results that are never retried. OAuth, legacy SSE, and MCP resources/prompts are out of scope. Release chapter-09 (version 0.9.0).
10	Released	Keep the Agent within its authorization with guardrails	How do the scattered controls from Chapters 02–09 become one policy enforced in code? Every live tool call passes one allow/ask/deny decision before anything runs: built-in protected paths such as .env, keys, and .git/ that file tools may never read or write in any mode, then a per-session permission mode that only the user changes with /mode. manual, the mode every session starts in, asks before every write, Bash, and MCP call; accept-edits also runs project file writes and edits unasked; bypass runs every call unasked. Loosening needs an interactive confirmation, /new starts in manual and /resume restores that session's mode, modes are never saved, and unasked calls are still shown. Approvals stay bound to the single inspected call, and injected text, summaries, or tool output cannot grant permission. There is no OS sandbox; the lesson explains why Bash and MCP processes remain outside path rules. Verify with injection, symbolic-link, mode, and /mode cases using mock services. Release chapter-10 (version 0.10.0).
11	Released	Measure the Agent with evals	How do you check repeatably whether a change to the SOUL, a tool description, or the loop changed what the Agent does? mino eval runs YAML cases, each declaring a prompt, what to approve, an optional scripted model, and deterministic graders, through the real Agent loop. Replay mode drives the loop with a scripted loopback Responses service: no key, no network, never reads ~/.mino, and runs in scripts/check.sh. --live repeats each case against the configured model and reports pass@k, pass^k, and token usage. Every run uses a fresh temporary workspace and home, the manual permission mode, and no MCP servers. There is no judge model and no sandbox; history stays at record version 4. Release chapter-11 (version 0.11.0).
12	Released	Run Bash inside an operating-system sandbox	Chapters 10 and 11 state that the policy confines file tools but not the processes Bash and MCP start. How can the execution environment, rather than a guess about a command's intent, bound what a command may touch? On macOS, every Bash command runs under a Seatbelt profile (sandbox-exec) that allows reads, confines writes to the project directory, temporary directories, and per-user caches, denies the built-in protected paths (.git/ readable but not writable), and blocks the network. The confirmation shows a Sandbox line; the model may set sandbox: false for a command that needs more, which asks in every mode except bypass; accept-edits runs confined commands unasked. mino mcp add --sandbox confines a stdio server with the network allowed. Where sandbox-exec is missing, Bash behaves as in Chapter 11 and says so. History stays at record version 4. Release chapter-12 (version 0.12.0).
13	Released	Remember the user across sessions	What should Mino remember across sessions and projects, where does it live, and how does model-written text enter the context without becoming an instruction? Each memory is one file in ~/.mino/memory/ with a name, a type (user, feedback, project, reference), and a one-line summary, plus optional details. There is no index file: at the start of every turn Mino renders an index of all summaries from the files and sends it as the first input item, an assistant message labeled as data rather than instructions, merged with any compaction summary and never written to history. The summary is the fact itself; memory_view reads a memory's details without a question, and memory_save creates or overwrites one after approval in manual and accept-edits, unasked only in bypass. The index is bounded to 200 entries and 16 KiB; unusable files are skipped with a notice. No delete tool, no project-local memory, no automatic extraction. History stays at record version 4. Release chapter-13 (version 0.13.0).
14	Released	Delegate work to subagents	How does a large exploration avoid crowding the main loop's context, and what does a child loop inherit? One spawn_agent call takes 1 to 10 tasks and runs each as a child Agent with its own context, its own log under ~/.mino/sessions/<session-id>.agents/, its own request and tool limits, and its own compaction, three at a time by default (max_concurrent_subagents, 1 to 10). Children receive the startup SOUL, the session's skill catalog, the turn's memory index, and the same tools except spawn_agent and memory_save; they share the session's permission mode, and their questions ask one at a time with a Subagent label. spawn_agent itself asks in manual and accept-edits, and a turn can start at most 16 subagents. The parent waits and receives one tool result with each task's status and final text within a shared 48 KiB budget, so its history keeps one start and one result per call at record version 4. The sandbox now also blocks ~/.mino. Release chapter-14 (version 0.14.0).
15	Released	Give subagents project roles	How does a project give the model reusable, specialised helpers without giving them authority? Definitions in .agents/agents/<name>.md name a role, describe when to use it, may narrow its tools with a tools list, and hold role text. Their metadata is saved once per session in a new session_agents record, like the skill catalog, and listed in the parent's instructions; spawn_agent tasks become {agent, task} objects, and an unknown role is rejected before confirmation. A role's subagent receives the definition's current text in its first message as labelled project data, never as instructions, and only the listed tools that are available; a definition cannot add tools, change the model or permission mode, or grant approval. A built-in create-subagent skill guides the model in writing one, and skill_view results now name the skill's directory. History moves to record version 5. Planned release chapter-15 (version 0.15.0).

Basic protections arrive alongside the capabilities that need them: Chapter 03 approves each Bash command, Chapter 04 refuses to treat an unknown result as success, Chapter 08 confines file access by construction, and Chapter 09 approves each external tool call and keeps service credentials away from the model. Chapter 10 consolidates existing controls rather than adding the first ones, and Chapter 11 makes their effect on the model measurable: the same cases run through the same loop and decision, so a change to the SOUL or a tool description is checked by repetition rather than by one impression. Prompts and injection detection can reduce risk, but the program and execution environment must enforce actual permissions. Checking only command keywords such as rm is not a sufficient policy, and a general Bash tool cannot be confined by path rules alone; that contrast is why structured file tools come before guardrails.