@miphamai/cli 0.85.2 → 0.85.3

package/src/shared/arg-validation.ts

@@ -6,8 +6,16 @@
  * a leftover argument as an unknown command (positional) or unknown option
  * (leading `-`/`--`) and suggests the closest known alternative via
  * Levenshtein distance, instead of silently launching the interactive CLI.
+ *
+ * It also owns the **value** domain of the one flag whose value is a named thing:
+ * `parsePermissionFlag` below. Keeping the flag's spelling and its accepted values in
+ * one module is what stops "the flag is known" and "the flag's value is understood"
+ * from drifting apart.
  */
 
+import { ALL_MODES } from '../core/permission-config'
+import type { PermissionMode } from './types'
+
 export interface UnknownArgument {
   kind: 'command' | 'option'
   arg: string
@@ -38,6 +46,7 @@ const KNOWN_FLAGS = [
   '--dump-config',
   '--safe-mode',
   '--resume',
+  '--permission',
 ]
 
 /**
@@ -47,14 +56,21 @@ const KNOWN_FLAGS = [
  * start with `-`, concluded the user had typed a command, and reported
  * `Unknown command: mipham my session` — blaming the session name and never
  * mentioning `--resume`, the one argument that was actually wrong.
+ *
+ * `--permission` is here for the same reason and for one more: `mipham attach <id>
+ * --permission plan` reads the session id through `firstPositional`, and without this
+ * entry it would have taken `plan` for a session id.
  */
-const VALUE_FLAGS = ['--resume']
+const VALUE_FLAGS = ['--resume', '--permission']
 
 /**
  * The first token that would be read as a command, skipping flags and the values
  * of value-taking flags. `null` when there is none.
+ *
+ * Exported for `bin/mipham.ts`'s attach path, which picks its session id the same
+ * way: `args[1]` alone is wrong as soon as a value-taking flag comes first.
  */
-function firstPositional(args: string[]): string | null {
+export function firstPositional(args: string[]): string | null {
   for (let i = 0; i < args.length; i++) {
     const arg = args[i]!
     if (arg.startsWith('-')) {
@@ -111,3 +127,59 @@ export function detectUnknownArgument(args: string[]): UnknownArgument | null {
 
   return null
 }
+
+/**
+ * `--permission <mode>` — the mode the session starts in.
+ *
+ * The accepted set is `ALL_MODES`, i.e. **exactly what the daemon accepts over the
+ * wire** (its `set_mode` whitelist, pinned equal by
+ * `test/integrity/permission-status-parity.test.ts` P7e). One set, three doors —
+ * `config.yml`, this flag, the attach protocol — so a value legal at one door cannot be
+ * silently illegal at another. The list itself is never written out here: it is derived
+ * from `ALL_MODES` in both the message and `mipham --help`, because a hand-kept copy is
+ * what drifts the day a mode is added.
+ *
+ * Deliberately **not** the legacy three-level spellings (`self`/`ask`/`bypass`) that
+ * `setDefaultLevel` still maps. A flag is typed by the person reading its error message,
+ * which names the spellings it takes; and `bypass` is a value the daemon rejects, so
+ * accepting it here would make the same flag work locally and fail under
+ * `mipham attach` — silently, since the daemon's answer is a correction, not an error.
+ *
+ * An unrecognized value is an **error**, never a fallback to `default`: `default` is
+ * *wider* than most of what a user would have meant (`plan`, `acceptEdits`), so falling
+ * back is a silent widening — the fail-open shape this file exists to prevent. Same
+ * reasoning as bin's `--resume` guard, which refuses an unknown session name rather than
+ * quietly starting a fresh one.
+ *
+ * Space form only (`--permission plan`), like `--resume`. The `=` form is refused **here**
+ * rather than left to `detectUnknownArgument`, because `mipham attach` never runs that
+ * scan (it returns before it) — without this line `mipham attach <id> --permission=plan`
+ * would attach with the flag silently doing nothing, on the one path where nothing else
+ * would have caught it.
+ */
+export function parsePermissionFlag(
+  args: string[],
+): { kind: 'absent' } | { kind: 'ok'; mode: PermissionMode } | { kind: 'error'; message: string } {
+  const eqForm = args.find((a) => a.startsWith('--permission='))
+  if (eqForm) {
+    return {
+      kind: 'error',
+      message: `--permission takes its value as a separate argument: mipham --permission <mode> (got "${eqForm}")`,
+    }
+  }
+
+  const at = args.indexOf('--permission')
+  if (at === -1) return { kind: 'absent' }
+
+  const raw = args[at + 1]
+  if (!raw || raw.startsWith('-')) {
+    return { kind: 'error', message: `Usage: mipham --permission <${ALL_MODES.join('|')}>` }
+  }
+  if (!ALL_MODES.includes(raw as PermissionMode)) {
+    return {
+      kind: 'error',
+      message: `Unknown permission mode: ${raw}\nValid modes: ${ALL_MODES.join(', ')}`,
+    }
+  }
+  return { kind: 'ok', mode: raw as PermissionMode }
+}

package/src/shared/package-info.ts

@@ -9,7 +9,7 @@
 export const PACKAGE_NAME = '@miphamai/cli' as const
 
 /** 当前发布版本 */
-export const PACKAGE_VERSION = '0.85.2' as const
+export const PACKAGE_VERSION = '0.85.3' as const
 
 /** npm install 全局安装命令 */
 export const NPM_INSTALL_COMMAND = `npm install -g ${PACKAGE_NAME}` as const

package/src/skills/bundled-skills.ts

@@ -18,7 +18,7 @@ export const BUNDLED_SKILLS: ReadonlyArray<BundledSkill> = [
   { type: 'standard', raw: "---\nname: grill-with-docs\ndescription: A relentless interview to sharpen a plan or design, creating CONTEXT.md (shared language) and ADRs (architectural decisions) as we go. Use before any non-trivial implementation to align on requirements and terminology.\nversion: 1.0.0\nuser-invocable: true\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Bash\n  - Glob\n  - Grep\n  - WebSearch\n  - WebFetch\n---\n\n# Grill With Docs — Deep Requirements Alignment\n\nInspired by Matt Pocock's `grill-with-docs` and `domain-modeling` skills. Before writing code, run a structured interview to align on requirements, establish shared language, and record architectural decisions.\n\n## When to Use\n\n- Before any non-trivial feature implementation\n- When requirements are fuzzy (\"make it faster\", \"add X\")\n- When you need to establish project terminology\n- When architectural decisions need to be recorded\n- User says: \"plan X\", \"design Y\", \"what should we do about Z\"\n\n## When NOT to Use\n\n- Trivial bug fixes with clear expected behavior\n- One-line changes\n- Tasks where the requirements are already crystal clear\n\n---\n\n## The Interview Flow\n\n### Phase 1: Understand the Intent\n\nStart by understanding what the user actually wants. Don't ask \"what should I build?\" — ask about their goal.\n\n**Core Questions:**\n\n1. What problem are you solving? (Not what feature you're building)\n2. Who is this for? (End user, developer, internal tool?)\n3. What does success look like? (How will you know when it's done?)\n4. What's the deadline or priority context?\n\n**Anti-pattern**: Jumping to implementation questions (\"Do you want REST or GraphQL?\") before understanding the problem.\n\n### Phase 2: Sharpen the Language\n\nIdentify vague or overloaded terms and pin them down **immediately**. This is the single highest-leverage activity — shared language reduces token waste and prevents misunderstandings.\n\n**Technique: The Canonical Term**\n\n- When the user uses multiple words for the same thing, pick one as canonical\n- List rejected alternatives under `_Avoid_`\n- Be opinionated — the glossary is prescriptive, not descriptive\n\n```\nUser: \"We need a way for users to save articles for later.\"\nYou: \"Let's pin that down. 'Save for later' could mean bookmarking, or a reading list, or offline download. Which one?\"\nUser: \"Like a reading list — they can come back to it.\"\nYou: \"Got it. Let's call it a **Reading List**. Avoid 'bookmark', 'save', 'favorites'.\"\n→ Write to CONTEXT.md immediately.\n```\n\n**Technique: The Boundary Test**\n\n- When a term is proposed, test its boundaries with edge cases\n- \"Does X include Y? What about Z?\"\n\n**Technique: The Code Cross-Reference**\n\n- When the user describes how something works, check if existing code agrees\n- Surface contradictions immediately\n\n### Phase 3: Probe Edge Cases\n\nBefore accepting any requirement, stress-test it with edge cases.\n\n**Edge Case Inventory:**\n\n- **Empty state**: What does the user see when there's nothing yet?\n- **Error state**: What happens when things go wrong?\n- **Extreme values**: What about 0? What about 10,000?\n- **Concurrency**: What if two people do this at the same time?\n- **Permissions**: Who can do this? Who cannot?\n- **Scale**: What changes at 10x the current volume?\n\n**Technique: The 5 Whys**\nWhen a requirement seems odd, dig deeper:\n\n```\nUser: \"We need real-time updates.\"\nYou: \"Why real-time?\"\nUser: \"Because users need to see changes immediately.\"\nYou: \"Why do they need to see changes immediately?\"\nUser: \"Because they're collaborating on the same document.\"\n→ Now you know the REAL requirement is collaboration, not real-time.\n```\n\n### Phase 4: Make Architecture Decisions\n\nWhen a design decision meets ALL three criteria, offer to record it as an ADR:\n\n1. **Hard to reverse** — changing your mind later has real cost\n2. **Surprising without context** — a future reader would wonder \"why?\"\n3. **The result of a real trade-off** — there were genuine alternatives\n\n**What qualifies for an ADR:**\n\n- Architecture shape (monorepo vs polyrepo, event sourcing vs CRUD)\n- Integration patterns between contexts\n- Technology choices with lock-in (database, message bus, auth provider)\n- Deliberate deviations from convention (\"we use raw SQL because...\")\n- Constraints not visible in code (\"we can't use X because compliance\")\n\n**ADR Format** (write to `docs/adr/NNNN-slug.md`):\n\n```markdown\n# {Short title of the decision}\n\n{1-3 sentences: context, decision, and why.}\n```\n\nOnly add optional sections (Status, Considered Options, Consequences) when they add genuine value. Most ADRs are a single paragraph.\n\n### Phase 5: Write the CONTEXT.md\n\nAfter the interview, synthesize everything into `CONTEXT.md`.\n\n**Format** (`CONTEXT.md` at project root):\n\n```markdown\n# {Project Name} Context\n\n{One or two sentence description of the project domain.}\n\n## Language\n\n**{Term}**:\n{One or two sentence definition of what it IS.}\n_Avoid_: {alternative terms that should not be used}\n\n## Decisions\n\n- [ADR 0001: {Title}](docs/adr/0001-slug.md) — {one-line summary}\n```\n\n**Rules:**\n\n- Be opinionated — pick the best term, ban the rest\n- Only include domain-specific terms (not general programming concepts)\n- Keep definitions tight — one or two sentences\n- Update inline during the conversation, don't batch\n- CONTEXT.md is a glossary, NOT a spec or implementation plan\n\n---\n\n## During the Conversation\n\n### DO\n\n- Challenge the user when they use vague terms — \"What do you mean by 'fast'?\"\n- Propose canonical terms and write them down immediately\n- Invent edge cases and probe boundaries\n- Offer ADRs sparingly (only when all 3 criteria are met)\n- Cross-reference with existing code if available\n- Call out contradictions between what the user says and what the code does\n\n### DON'T\n\n- Rush to implementation questions before understanding the problem\n- Write ADRs for trivial decisions\n- Let fuzzy language slide — pin it down now or pay later\n- Treat CONTEXT.md as a spec or scratch pad\n- Ask yes/no questions when open-ended ones would reveal more\n\n---\n\n## Output\n\nAfter the interview, the user should have:\n\n1. **CONTEXT.md** — shared language glossary (created or updated)\n2. **ADRs** (if needed) — architectural decisions in `docs/adr/`\n3. **Clear requirements** — edge cases explored, assumptions surfaced\n4. **Shared understanding** — you and the user now mean the same thing by the same words\n\n---\n\n## Integration with Mipham Code\n\n- **Memory System**: Key terms go to project memory for persistence across sessions\n- **Critical Thinking Layer**: Apply the 5-dimension self-check (evidence standard, equivalence verification, counter-example search, confidence calibration, depth check) to your own interview questions\n- **Workflow**: For complex projects, the output of this skill feeds directly into `/implement`\n" },
   { type: 'standard', raw: "---\nname: implement\ndescription: Build work from a spec or tickets with systematic discipline — TDD at pre-agreed seams, incremental verification, code review before commit. Use when implementing features, bugfixes, or any planned work.\nversion: 1.0.0\nuser-invocable: true\n---\n\n# Implement — Structured Build Execution\n\n融合 Superpowers executing-plans（计划审阅 + 隔离工作区）+ Matt Pocock implement（TDD 接缝 + 增量验证 + 提交前审查）。\n\n## When to Use\n\n- Implementing work from a written spec or ticket set\n- Executing a development plan with clear deliverables\n- Building a feature with predefined success criteria\n\n## When NOT to Use\n\n- Exploratory coding / prototyping → use `prototype` skill\n- Quick one-line fixes → just fix it\n- No spec or tickets exist → use `to-tickets` or `to-spec` first\n\n---\n\n## Step 1: Load and Review\n\n### 1.1 Ensure isolated workspace\n\nUse git worktree or a feature branch. Never implement on main/master without explicit consent.\n\n### 1.2 Read the plan/spec/tickets\n\nRead the full spec or ticket set. Understand:\n\n- What is being built?\n- What are the acceptance criteria?\n- What are the pre-agreed seams (where TDD should be applied)?\n\n### 1.3 Review critically\n\nBefore writing any code:\n\n- Are there gaps or ambiguities in the spec?\n- Are the success criteria testable?\n- Do you understand every instruction?\n\n**If concerns exist, raise them before starting.** Don't guess.\n\n---\n\n## Step 2: Execute Tasks\n\nFor each task in order:\n\n### 2.1 At pre-agreed seams: TDD\n\nWhere the spec specifies (or where interfaces are well-defined):\n\n1. Write a **failing test** that asserts the expected behavior\n2. Watch it fail (red)\n3. Write the **minimum code** to make it pass (green)\n4. Refactor if needed, keeping tests green\n\nUse the `tdd` skill for full red-green-refactor discipline.\n\n### 2.2 Incremental verification\n\nDuring implementation:\n\n- **Run typecheck** after each significant change: `pnpm typecheck`\n- **Run relevant test file** after each task: `pnpm test -- <file>`\n- **Don't wait** until everything is done to discover type errors\n\n### 2.3 One task at a time\n\n- Follow each step exactly — the plan has bite-sized steps for a reason\n- One change at a time. No \"while I'm here\" improvements.\n- Mark tasks as complete after verification passes\n\n---\n\n## Step 3: Final Verification\n\nAfter all tasks are complete:\n\n### 3.1 Full test suite\n\n```bash\npnpm test\n```\n\nAll tests must pass. If any fail, fix before proceeding.\n\n### 3.2 Lint and format\n\n```bash\npnpm lint\npnpm format\n```\n\nCI must be green.\n\n---\n\n## Step 4: Code Review\n\n**Before committing**, run code review:\n\nUse the `code-review` skill for a two-axis review:\n\n- **Standards**: Does the diff follow the repo's coding standards?\n- **Spec**: Does it faithfully implement the originating issue/spec?\n\nFix any findings before committing.\n\n---\n\n## Step 5: Commit\n\nCommit your work to the current branch.\n\n```bash\ngit add -A\ngit commit -m \"<type>: <description>\"\n```\n\n- Follow Conventional Commits\n- Reference the spec/ticket in the commit message\n- **Do NOT commit unless explicitly asked** (per CLAUDE.md §关键约束)\n\n---\n\n## When to Stop and Ask\n\n**STOP immediately when:**\n\n- A task is blocked (missing dependency, unclear instruction, verification fails repeatedly)\n- The spec has a critical gap that prevents starting\n- You don't understand an instruction\n- 3+ fix attempts fail — this may be an architectural issue\n\n**Ask for clarification rather than guessing.**\n\n---\n\n## Quick Reference\n\n| Step           | Key Activities                                               | Done When                        |\n| -------------- | ------------------------------------------------------------ | -------------------------------- |\n| **1. Review**  | Load spec, isolate workspace, review critically              | All concerns raised and resolved |\n| **2. Execute** | TDD at seams, incremental typecheck/test, one task at a time | All tasks complete and verified  |\n| **3. Verify**  | Full test suite, lint, format                                | CI-ready (all green)             |\n| **4. Review**  | Two-axis code review (standards + spec)                      | Findings addressed               |\n| **5. Commit**  | Conventional Commits, reference spec/ticket                  | Work committed to branch         |\n" },
   { type: 'standard', raw: "---\nname: memory\ndescription: Read and write persistent memory files for context retention across sessions — one fact per file with frontmatter\nversion: 2.0.0\n---\n\n# Memory Skill\n\nManage persistent memory stored as markdown files with YAML frontmatter.\n\n## File Format\n\nEach memory is one `.md` file under the `memory/` directory:\n\n```markdown\n---\nname: <kebab-case-slug>\ndescription: <one-line summary>\nmetadata:\n  type: user | feedback | project | reference\n---\n\n<the fact body>\n\n**Why:** <rationale>\n**How to apply:** <practical guidance>\n```\n\n## File Path Conventions\n\n- Directory: `~/.mipham/memory/` (user-level) or `./.mipham/memory/` (project-level)\n- Filename: `<name-slug>.md` (lowercase, hyphens)\n- Index: `MEMORY.md` — one line per memory file, maintained automatically\n\n## Operations\n\n### List Memories\n\nScan `MEMORY.md` index for available memories. The index has one line per memory:\n\n```markdown\n- [Title](file.md) — brief hook\n```\n\n### Read Memory\n\nRead the full markdown file including frontmatter. Parse YAML frontmatter for metadata.\n\n### Write Memory\n\n1. Check for existing file with same `name:` slug — update if found\n2. Create new file if no match\n3. Add/update entry in `MEMORY.md` index\n4. Never write what the repo already records (code structure, git history, CLAUDE.md)\n\n### Delete Memory\n\nRemove the file and its index entry. Use when a memory is incorrect or superseded.\n\n## Best Practices\n\n- **One fact per file** — atomic, focused, easy to find\n- **Descriptive slugs** — `npm-publish-workflow` not `memory-1`\n- **Link related memories** — use `[[slug-name]]` wikilinks in body\n- **Check before writing** — search existing memories to avoid duplicates\n- **Types matter**: `user` (who), `feedback` (corrections), `project` (goals), `reference` (external)\n\n## Example\n\n```markdown\n---\nname: api-rate-limit\ndescription: OpenAI API has 500 RPM limit on our tier\nmetadata:\n  type: reference\n---\n\nThe OpenAI API key for production has a hard 500 requests/minute limit.\nExceeding it returns HTTP 429 with a Retry-After header.\n\n**Why:** We hit this in production during peak usage\n**How to apply:** Use exponential backoff; batch requests where possible\n```\n" },
-  { type: 'standard', raw: "---\nname: mipham-code-setup\ndescription: Install, configure, diagnose, and troubleshoot Mipham Code — the multi-model open-core intelligent coding terminal. Covers setup wizard, API keys, providers, models, skills, permissions, workspace trust, shell/IDE integration, and first-run onboarding.\nversion: 2.0.0\nuser-invocable: true\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Bash\n  - Skill\n---\n\n# Mipham Code Setup — Executable Setup Workflow\n\n**Type**: Rigid — follow the decision tree exactly. Don't skip diagnostic phases.\n\n**Purpose**: Guide users from zero to fully configured Mipham Code. This skill is BOTH:\n\n1. A self-contained diagnostic + configuration workflow the AI can execute\n2. A reference for `/setup` command behavior and slash commands\n\n**Triggers**: \"setup mipham\", \"configure mipham\", \"install mipham code\", \"mipham not working\", \"mipham setup\", \"first time using mipham\", \"help me set up\", \"getting started\", `/setup`\n\n---\n\n## Phase 0: Environment Detection (ALWAYS RUN FIRST)\n\nBefore doing anything, run these diagnostic checks. Report results in a status table.\n\n### 0.1 — Detect Installation\n\n```bash\nwhich mipham 2>/dev/null\nmipham --version 2>/dev/null\nbun --version 2>/dev/null\nnode --version 2>/dev/null\n```\n\n### 0.2 — Detect Configuration\n\n```bash\nls -la .mipham/config.yml 2>/dev/null\nls -la ~/.mipham/config.yml 2>/dev/null\nls -la MIPHAM.md 2>/dev/null\nls -la CLAUDE.md 2>/dev/null\n```\n\n### 0.3 — Detect API Keys\n\n```bash\nenv | grep -E 'ANTHROPIC_API_KEY|OPENAI_API_KEY|DEEPSEEK_API_KEY|QWEN_API_KEY|DOUBAO_API_KEY|HUNYUAN_API_KEY|GEMINI_API_KEY' | cut -d= -f1\n```\n\n### 0.4 — Detect Skills & Permissions\n\n```bash\nls .mipham/skills/ 2>/dev/null\ncat .mipham/config.yml 2>/dev/null | grep -E 'permission|trust' || echo \"no config\"\n```\n\n### 0.5 — Detect Workspace Trust\n\n```bash\ncat ~/.mipham/trusted-workspaces.json 2>/dev/null || echo \"no trust store\"\n```\n\n### Status Report Format\n\nAfter detection, present results as:\n\n```\n── Mipham Code Status ──\n\nInstallation:  [✅/⬜] mipham CLI  [✅/⬜] Bun  [✅/⬜] Node.js\nProject:       [✅/⬜] .mipham/  [✅/⬜] config.yml  [✅/⬜] MIPHAM.md\nUser Config:   [✅/⬜] ~/.mipham/config.yml\nAPI Keys:      [N] set (list names or \"none\")\nSkills:        [N] installed\nPermissions:   [mode] (default/acceptEdits/plan/auto/bypassPermissions)\nTrust:         [✅/⬜] workspace trusted\n```\n\nThen proceed to ONLY the phases where something is missing. Don't re-run already-configured steps unless asked.\n\n---\n\n## Phase 1: Installation\n\n**Trigger**: `mipham --version` fails.\n\n### Option A: Quick Install (recommended)\n\n```bash\ncurl -fsSL https://mipham.ai/install.sh | bash\n```\n\nThen restart the shell or run:\n\n```bash\nexport PATH=\"$HOME/.mipham/bin:$PATH\"\n```\n\n### Option B: npm Global Install\n\n```bash\nnpm install -g @miphamai/cli\nmipham\n```\n\n### Option C: From Source (developers)\n\n```bash\ngit clone https://github.com/One-Mipham/mipham-code\ncd mipham-code/apps/cli\nbun install && bun run bin/mipham\n```\n\n### ✅ Verification\n\n```bash\nmipham --version   # Should print version ≥ 0.24.0\nmipham --help      # Should print usage\n```\n\n---\n\n## Phase 2: Project Initialization\n\n**Trigger**: Missing `.mipham/` directory or `MIPHAM.md`.\n\n### 2.1 — Create .mipham/ directory\n\n```bash\nmkdir -p .mipham\n```\n\n### 2.2 — Create .mipham/config.yml\n\nWrite a minimal config. Ask the user which provider they want to use first, or pick a sensible default:\n\n```yaml\ndefaultProvider: anthropic\ndefaultModel: claude-sonnet-4-6\npermission: default\n```\n\n**Providers available** (alphabetical):\n\n| Provider  | Type          | Example Models                         |\n| --------- | ------------- | -------------------------------------- |\n| anthropic | Native SDK    | Claude Haiku 4.5, Sonnet 4.6, Opus 4.8 |\n| deepseek  | OpenAI Compat | V4 Flash, V4 Pro                       |\n| doubao    | OpenAI Compat | Seed 1.6, Seed 2.0                     |\n| gemini    | OpenAI Compat | 3.0 Flash, 3.0 Pro, 2.5 Pro            |\n| hunyuan   | OpenAI Compat | Lite, TurboS, 2.0, T1                  |\n| openai    | OpenAI Compat | GPT-5.4 Mini, GPT-5.4, GPT-5.5, Codex  |\n| qwen      | OpenAI Compat | Qwen Plus, Qwen Max                    |\n\n### 2.3 — Create MIPHAM.md (optional but recommended)\n\nCreate `MIPHAM.md` in project root to define AI personality:\n\n```markdown\n# MIPHAM.md\n\n## Project Context\n\n- **Project**: [name]\n- **Language**: [zh-CN / en]\n- **Stack**: [TypeScript / Python / etc.]\n\n## Preferences\n\n- Code style: [e.g., functional, OOP]\n- Comment language: [e.g., English]\n- Test framework: [e.g., Vitest]\n```\n\n### ✅ Verification\n\n```bash\nls -la .mipham/config.yml MIPHAM.md\n```\n\n---\n\n## Phase 3: API Key Configuration\n\n**Trigger**: Missing API keys in environment.\n\n### 3.1 — Identify Required Providers\n\nAsk the user which providers they plan to use. For each, set the env var.\n\n### 3.2 — Set API Keys\n\n**Recommended: Environment variables** (not in config files — avoids accidental commits):\n\n```bash\nexport ANTHROPIC_API_KEY=\"sk-ant-...\"\nexport OPENAI_API_KEY=\"sk-...\"\nexport DEEPSEEK_API_KEY=\"sk-...\"\nexport QWEN_API_KEY=\"sk-...\"\nexport DOUBAO_API_KEY=\"...\"\nexport HUNYUAN_API_KEY=\"...\"\nexport GEMINI_API_KEY=\"...\"\n```\n\nAdd these to `~/.zshrc` or `~/.bashrc` for persistence:\n\n```bash\necho 'export ANTHROPIC_API_KEY=\"sk-ant-...\"' >> ~/.zshrc\nsource ~/.zshrc\n```\n\n**Alternative**: Store in `~/.mipham/config.yml`:\n\n```yaml\nproviders:\n  - id: anthropic\n    apiKey: $ANTHROPIC_API_KEY\n  - id: openai\n    apiKey: $OPENAI_API_KEY\n```\n\n### 3.3 — Verify Keys\n\n```bash\nenv | grep API_KEY\n```\n\n### ❗Security Rules\n\n- NEVER hardcode API keys in project config files (`.mipham/config.yml` in project root should use `$ENV_VAR` references, not raw keys)\n- NEVER commit API keys to git\n- Add to `.gitignore`: `.mipham/config.yml` (if it contains keys), `.env`, `*.pem`\n\n---\n\n## Phase 4: Provider & Model Configuration\n\n**Trigger**: Need to set default or enable/disable providers.\n\n### 4.1 — Set Default Provider & Model\n\nIn `.mipham/config.yml`:\n\n```yaml\ndefaultProvider: anthropic\ndefaultModel: claude-sonnet-4-6\n```\n\nOr use slash commands:\n\n```\n/model          # Interactive model picker (Ctrl+P)\n/switch         # Switch provider\n/providers      # List all configured providers\n```\n\n### 4.2 — Enable/Disable Providers\n\n```yaml\nproviders:\n  - id: anthropic\n    status: active\n  - id: openai\n    status: active\n  - id: deepseek\n    status: disabled\n```\n\n### ✅ Verification\n\n```\n/model    # Should show available models\n/providers # Should list active providers\n```\n\n---\n\n## Phase 5: Skills Installation\n\n**Trigger**: No or few skills installed.\n\n### 5.1 — Built-in Skills\n\nMipham Code ships with 28 built-in skills loaded automatically:\n\n- **Standard (22)**: code-review, codebase-design, compassionate-communication, debug-loop, doc-generator, domain-modeling, github-ops, grill-with-docs, implement, memory, mipham-code-setup, research, safe-coding, security-review, self-review, superpower, tdd, to-spec, triage, trim-process-prose, web-access, web-search\n- **Mipham (6)**: doc-sync, om-artifact, om-model-optimize, om-security, save-to-wiki, self-audit\n\n### 5.2 — Community Skills\n\nInstall from the community registry:\n\n```\n/setup 4     # Guided skill browser\n```\n\nOr directly:\n\n```bash\n# Skills are loaded from:\n# - apps/cli/skills/standard/     (built-in standard)\n# - apps/cli/skills/mipham/       (built-in mipham)\n# - ~/.mipham/skills/             (user-installed)\n# - .mipham/skills/               (project-local)\n```\n\n### 5.3 — Install Specific Skills\n\n```\n/skills install <name>    # Install from registry\n/skills list              # List available\n/skills search <query>    # Search registry\n```\n\n### ✅ Verification\n\n```\n/skills list   # Should show installed skills with counts\n```\n\n---\n\n## Phase 6: Permissions Configuration\n\n**Trigger**: Permission mode not configured or wrong for use case.\n\n### 6.1 — Permission Modes\n\n| Mode                | Behavior                               | Use Case                                  |\n| ------------------- | -------------------------------------- | ----------------------------------------- |\n| `default`           | Ask-first tools are refused (see note) | Normal development (recommended)          |\n| `acceptEdits`       | Auto-allow edits, ask for other tools  | Active coding sessions                    |\n| `plan`              | Plan-only, no tool execution           | Design & architecture work                |\n| `auto`              | A classifier rules on every call       | Long unattended runs you still want gated |\n| `bypassPermissions` | Skip all checks                        | ⚠️ Only for fully trusted codebases       |\n\n**Note on `default`**: Mipham Code has no interactive approval prompt, so \"ask\"\nmeans the call is **refused** with a message naming the mode — it is not queued\nfor your answer. That makes `default` the strictest _usable_ mode for Bash and\nfile writes; `auto` is the mode that lets gated calls proceed without a human,\nby having a classifier rule on each one.\n\n**What `auto` actually gates.** Reads (Read/Grep/Glob) are never sent to the\nclassifier — gating them would make `auto` the only mode in the ladder that cannot\nopen a file without a round-trip to another model. Everything else that the static\nchain would refuse goes to the classifier, which can only **lift** a refusal: a\ndeny rule or an `ask` rule is never overridden. If the classifier cannot be reached\nor answers unusably, the call is refused (fail-closed) with a message saying the\nrefusal is _not_ a policy decision and can be retried.\n\n### 6.2 — Configure\n\nPress **Shift+Tab** to change the mode live; it cycles\n`default → acceptEdits → plan → auto` and lasts for the session only.\n`bypassPermissions` is a legal mode but is deliberately **not** on the wheel —\nit is reached by naming it in config, where the user has said what they mean.\n\nTo persist a mode for a project, in `.mipham/config.yml`:\n\n```yaml\npermission: default\n```\n\nAny mode name from the table above is accepted, including `bypassPermissions`.\n\nOr via slash command:\n\n```\n/permissions           # View current settings\n/setup 5               # Permission setup wizard\n```\n\n### 6.3 — CI/CD Safety\n\nFor CI/CD environments, use the `default` mode (the daemon default): headless\nsessions never prompt, so `ask`-level tools (Bash/Write/Edit) are blocked rather\nthan auto-approved.\n\n### ✅ Verification\n\n```\n/permissions   # Should show current mode\n```\n\n---\n\n## Phase 7: Workspace Trust\n\n**Trigger**: Untrusted workspace (prompted on startup in v0.24.3+).\n\n### 7.1 — Understanding Workspace Trust\n\nWorkspace trust is a security mechanism that prevents AI from operating in untrusted directories. Trust is **hierarchical**: trusting `/Users/me/Projects` implicitly trusts all subdirectories.\n\n### 7.2 — Trust a Workspace\n\n**Interactive**: Accept the trust prompt when launching Mipham Code in a new directory.\n\n**Manual**:\n\n```\n/trust              # Show trust status\n/trust add <dir>    # Trust a directory\n/trust remove <dir> # Revoke trust\n```\n\n### 7.3 — Trust Store\n\n```\n~/.mipham/trusted-workspaces.json\n```\n\n### 7.4 — Auto-Trust for Worktrees\n\nWhen using git worktrees, Mipham Code automatically trusts worktree directories if the parent workspace is already trusted (via `EnterWorktree`).\n\n### ✅ Verification\n\n```\n/trust   # Should show \"✅ Yes\" for current directory\n```\n\n---\n\n## Phase 8: Shell & IDE Integration\n\n**Trigger**: Want terminal integration, aliases, or IDE plugins.\n\n### 8.1 — Shell Alias\n\nAdd to `~/.zshrc` or `~/.bashrc`:\n\n```bash\nalias mipham='cd ~/your-project && bun run ~/path/to/mipham-code/apps/cli/bin/mipham.ts'\n# Or if installed globally:\nalias mipham='mipham'\n```\n\n### 8.2 — VS Code Integration\n\nRun `/ide` to auto-generate `.vscode/` config files:\n\n- `settings.json` — terminal profile \"mipham\" using Bun\n- `keybindings.json` — Cmd+Esc to focus terminal, Cmd+Shift+M for new terminal\n- `extensions.json` — recommends `miphamai.mipham-code` extension\n\nTo use after generation:\n\n1. Restart VS Code (or Cmd+Shift+P → Reload Window)\n2. Open terminal: Ctrl+` or Cmd+Esc\n3. Select \"mipham\" profile from terminal dropdown\n\nInstall the VS Code extension:\n\n```bash\ncode --install-extension miphamai.mipham-code\n```\n\n### 8.3 — JetBrains Integration\n\nSettings → Tools → Terminal → Shell path → `bun run mipham`\n\n### 8.4 — Terminal Setup\n\n```\n/terminal-setup    # Shell & terminal config wizard\n/setup 6           # Shell integration (part of full wizard)\n```\n\n### ✅ Verification\n\n```bash\nwhich mipham       # Should resolve\n# In VS Code: Ctrl+` → select \"mipham\" profile\n```\n\n---\n\n## Phase 9: Full Verification\n\nRun after all configuration phases complete.\n\n### 9.1 — System Diagnostics\n\n```\n/doctor            # System diagnostics check\n```\n\n### 9.2 — End-to-End Test\n\nStart a conversation and verify:\n\n1. Model responds (not stuck on \"connecting...\")\n2. File tools work: \"read CLAUDE.md\"\n3. Bash works: \"list files in current directory\"\n4. Skills load: `/skills list`\n\n### 9.3 — Common Issues & Fixes\n\n| Symptom                   | Diagnosis                              | Fix                                              |\n| ------------------------- | -------------------------------------- | ------------------------------------------------ |\n| \"Provider not registered\" | Missing or invalid API key             | `env \\| grep API_KEY`; check key format          |\n| \"Model not found\"         | Model ID mismatch or disabled provider | `/models` to list available; `/switch` to change |\n| Slow responses            | Large model, network, or context full  | `/fast on` or switch to Flash model; `/compact`  |\n| Context full              | Too many messages in history           | `/compact` to compress; `/clear` to reset        |\n| Permission denied         | Tool blocked by permission mode        | `/permissions` to check; adjust mode             |\n| \"Workspace not trusted\"   | New directory, not yet trusted         | Accept startup prompt or run `/trust`            |\n| MCP tools not available   | Server not connected                   | `/mcp connect <name>` or check config            |\n| Update not applying       | Cached binary                          | `mipham update --force` then restart             |\n| Config changes ignored    | YAML syntax error                      | Validate with `mipham --check-config`            |\n\n### 9.4 — Get Help\n\n```\n/help              # Full command reference\n/setup             # Re-run setup wizard\n/doctor            # Run diagnostics\n```\n\nChat-based help: \"help me configure X\" or \"why isn't Y working?\"\n\n---\n\n## Quick Reference: Essential Slash Commands\n\n| Category      | Command           | Purpose                                                |\n| ------------- | ----------------- | ------------------------------------------------------ |\n| **Setup**     | `/setup`          | Full 6-step setup wizard                               |\n|               | `/setup 1`        | Initialize project (.mipham/ + MIPHAM.md + config.yml) |\n|               | `/setup 2`        | Configure providers & API keys                         |\n|               | `/setup 3`        | Choose default model                                   |\n|               | `/setup 4`        | Browse & install skills                                |\n|               | `/setup 5`        | Configure permissions                                  |\n|               | `/setup 6`        | Shell & IDE integration                                |\n| **Diagnosis** | `/doctor`         | System diagnostics                                     |\n|               | `/trust`          | Workspace trust status                                 |\n|               | `/permissions`    | Tool permission settings                               |\n| **Model**     | `/model`          | Interactive model picker (Ctrl+P)                      |\n|               | `/switch`         | Switch provider                                        |\n|               | `/models`         | List available models                                  |\n| **Session**   | `/clear`          | Reset conversation                                     |\n|               | `/compact`        | Compress context                                       |\n|               | `/rename`         | Rename session                                         |\n| **Workflow**  | `/plan`           | Enter plan mode                                        |\n|               | `/review`         | Code review                                            |\n|               | `/todos`          | Task list                                              |\n| **IDE**       | `/ide`            | Generate VS Code integration files                     |\n|               | `/terminal-setup` | Shell & terminal config                                |\n| **Skills**    | `/skills list`    | List installed skills                                  |\n|               | `/skills search`  | Search skill registry                                  |\n|               | `/skills install` | Install a skill                                        |\n\n---\n\n## Post-Setup: What to Do Next\n\nAfter configuration is verified:\n\n1. **Initialize your project**: \"help me understand this codebase\"\n2. **Set up CLAUDE.md**: `/init` to generate project documentation for the AI\n3. **Install relevant skills**: `/setup 4` or `/skills search`\n4. **Configure MCP servers**: `/mcp connect` for external tool integration\n5. **Start coding**: Just start a conversation — the AI will use tools and skills automatically\n" },
+  { type: 'standard', raw: "---\nname: mipham-code-setup\ndescription: Install, configure, diagnose, and troubleshoot Mipham Code — the multi-model open-core intelligent coding terminal. Covers setup wizard, API keys, providers, models, skills, permissions, workspace trust, shell/IDE integration, and first-run onboarding.\nversion: 2.0.0\nuser-invocable: true\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Bash\n  - Skill\n---\n\n# Mipham Code Setup — Executable Setup Workflow\n\n**Type**: Rigid — follow the decision tree exactly. Don't skip diagnostic phases.\n\n**Purpose**: Guide users from zero to fully configured Mipham Code. This skill is BOTH:\n\n1. A self-contained diagnostic + configuration workflow the AI can execute\n2. A reference for `/setup` command behavior and slash commands\n\n**Triggers**: \"setup mipham\", \"configure mipham\", \"install mipham code\", \"mipham not working\", \"mipham setup\", \"first time using mipham\", \"help me set up\", \"getting started\", `/setup`\n\n---\n\n## Phase 0: Environment Detection (ALWAYS RUN FIRST)\n\nBefore doing anything, run these diagnostic checks. Report results in a status table.\n\n### 0.1 — Detect Installation\n\n```bash\nwhich mipham 2>/dev/null\nmipham --version 2>/dev/null\nbun --version 2>/dev/null\nnode --version 2>/dev/null\n```\n\n### 0.2 — Detect Configuration\n\n```bash\nls -la .mipham/config.yml 2>/dev/null\nls -la ~/.mipham/config.yml 2>/dev/null\nls -la MIPHAM.md 2>/dev/null\nls -la CLAUDE.md 2>/dev/null\n```\n\n### 0.3 — Detect API Keys\n\n```bash\nenv | grep -E 'ANTHROPIC_API_KEY|OPENAI_API_KEY|DEEPSEEK_API_KEY|QWEN_API_KEY|DOUBAO_API_KEY|HUNYUAN_API_KEY|GEMINI_API_KEY' | cut -d= -f1\n```\n\n### 0.4 — Detect Skills & Permissions\n\n```bash\nls .mipham/skills/ 2>/dev/null\ncat .mipham/config.yml 2>/dev/null | grep -E 'permission|trust' || echo \"no config\"\n```\n\n### 0.5 — Detect Workspace Trust\n\n```bash\ncat ~/.mipham/trusted-workspaces.json 2>/dev/null || echo \"no trust store\"\n```\n\n### Status Report Format\n\nAfter detection, present results as:\n\n```\n── Mipham Code Status ──\n\nInstallation:  [✅/⬜] mipham CLI  [✅/⬜] Bun  [✅/⬜] Node.js\nProject:       [✅/⬜] .mipham/  [✅/⬜] config.yml  [✅/⬜] MIPHAM.md\nUser Config:   [✅/⬜] ~/.mipham/config.yml\nAPI Keys:      [N] set (list names or \"none\")\nSkills:        [N] installed\nPermissions:   [mode] (default/acceptEdits/plan/auto/bypassPermissions)\nTrust:         [✅/⬜] workspace trusted\n```\n\nThen proceed to ONLY the phases where something is missing. Don't re-run already-configured steps unless asked.\n\n---\n\n## Phase 1: Installation\n\n**Trigger**: `mipham --version` fails.\n\n### Option A: Quick Install (recommended)\n\n```bash\ncurl -fsSL https://mipham.ai/install.sh | bash\n```\n\nThen restart the shell or run:\n\n```bash\nexport PATH=\"$HOME/.mipham/bin:$PATH\"\n```\n\n### Option B: npm Global Install\n\n```bash\nnpm install -g @miphamai/cli\nmipham\n```\n\n### Option C: From Source (developers)\n\n```bash\ngit clone https://github.com/One-Mipham/mipham-code\ncd mipham-code/apps/cli\nbun install && bun run bin/mipham\n```\n\n### ✅ Verification\n\n```bash\nmipham --version   # Should print version ≥ 0.24.0\nmipham --help      # Should print usage\n```\n\n---\n\n## Phase 2: Project Initialization\n\n**Trigger**: Missing `.mipham/` directory or `MIPHAM.md`.\n\n### 2.1 — Create .mipham/ directory\n\n```bash\nmkdir -p .mipham\n```\n\n### 2.2 — Create .mipham/config.yml\n\nWrite a minimal config. Ask the user which provider they want to use first, or pick a sensible default:\n\n```yaml\ndefaultProvider: anthropic\ndefaultModel: claude-sonnet-4-6\npermission: default\n```\n\n**Providers available** (alphabetical):\n\n| Provider  | Type          | Example Models                         |\n| --------- | ------------- | -------------------------------------- |\n| anthropic | Native SDK    | Claude Haiku 4.5, Sonnet 4.6, Opus 4.8 |\n| deepseek  | OpenAI Compat | V4 Flash, V4 Pro                       |\n| doubao    | OpenAI Compat | Seed 1.6, Seed 2.0                     |\n| gemini    | OpenAI Compat | 3.0 Flash, 3.0 Pro, 2.5 Pro            |\n| hunyuan   | OpenAI Compat | Lite, TurboS, 2.0, T1                  |\n| openai    | OpenAI Compat | GPT-5.4 Mini, GPT-5.4, GPT-5.5, Codex  |\n| qwen      | OpenAI Compat | Qwen Plus, Qwen Max                    |\n\n### 2.3 — Create MIPHAM.md (optional but recommended)\n\nCreate `MIPHAM.md` in project root to define AI personality:\n\n```markdown\n# MIPHAM.md\n\n## Project Context\n\n- **Project**: [name]\n- **Language**: [zh-CN / en]\n- **Stack**: [TypeScript / Python / etc.]\n\n## Preferences\n\n- Code style: [e.g., functional, OOP]\n- Comment language: [e.g., English]\n- Test framework: [e.g., Vitest]\n```\n\n### ✅ Verification\n\n```bash\nls -la .mipham/config.yml MIPHAM.md\n```\n\n---\n\n## Phase 3: API Key Configuration\n\n**Trigger**: Missing API keys in environment.\n\n### 3.1 — Identify Required Providers\n\nAsk the user which providers they plan to use. For each, set the env var.\n\n### 3.2 — Set API Keys\n\n**Recommended: Environment variables** (not in config files — avoids accidental commits):\n\n```bash\nexport ANTHROPIC_API_KEY=\"sk-ant-...\"\nexport OPENAI_API_KEY=\"sk-...\"\nexport DEEPSEEK_API_KEY=\"sk-...\"\nexport QWEN_API_KEY=\"sk-...\"\nexport DOUBAO_API_KEY=\"...\"\nexport HUNYUAN_API_KEY=\"...\"\nexport GEMINI_API_KEY=\"...\"\n```\n\nAdd these to `~/.zshrc` or `~/.bashrc` for persistence:\n\n```bash\necho 'export ANTHROPIC_API_KEY=\"sk-ant-...\"' >> ~/.zshrc\nsource ~/.zshrc\n```\n\n**Alternative**: Store in `~/.mipham/config.yml`:\n\n```yaml\nproviders:\n  - id: anthropic\n    apiKey: $ANTHROPIC_API_KEY\n  - id: openai\n    apiKey: $OPENAI_API_KEY\n```\n\n### 3.3 — Verify Keys\n\n```bash\nenv | grep API_KEY\n```\n\n### ❗Security Rules\n\n- NEVER hardcode API keys in project config files (`.mipham/config.yml` in project root should use `$ENV_VAR` references, not raw keys)\n- NEVER commit API keys to git\n- Add to `.gitignore`: `.mipham/config.yml` (if it contains keys), `.env`, `*.pem`\n\n---\n\n## Phase 4: Provider & Model Configuration\n\n**Trigger**: Need to set default or enable/disable providers.\n\n### 4.1 — Set Default Provider & Model\n\nIn `.mipham/config.yml`:\n\n```yaml\ndefaultProvider: anthropic\ndefaultModel: claude-sonnet-4-6\n```\n\nOr use slash commands:\n\n```\n/model          # Interactive model picker (Ctrl+P)\n/switch         # Switch provider\n/providers      # List all configured providers\n```\n\n### 4.2 — Enable/Disable Providers\n\n```yaml\nproviders:\n  - id: anthropic\n    status: active\n  - id: openai\n    status: active\n  - id: deepseek\n    status: disabled\n```\n\n### ✅ Verification\n\n```\n/model    # Should show available models\n/providers # Should list active providers\n```\n\n---\n\n## Phase 5: Skills Installation\n\n**Trigger**: No or few skills installed.\n\n### 5.1 — Built-in Skills\n\nMipham Code ships with 28 built-in skills loaded automatically:\n\n- **Standard (22)**: code-review, codebase-design, compassionate-communication, debug-loop, doc-generator, domain-modeling, github-ops, grill-with-docs, implement, memory, mipham-code-setup, research, safe-coding, security-review, self-review, superpower, tdd, to-spec, triage, trim-process-prose, web-access, web-search\n- **Mipham (6)**: doc-sync, om-artifact, om-model-optimize, om-security, save-to-wiki, self-audit\n\n### 5.2 — Community Skills\n\nInstall from the community registry:\n\n```\n/setup 4     # Guided skill browser\n```\n\nOr directly:\n\n```bash\n# Skills are loaded from:\n# - apps/cli/skills/standard/     (built-in standard)\n# - apps/cli/skills/mipham/       (built-in mipham)\n# - ~/.mipham/skills/             (user-installed)\n# - .mipham/skills/               (project-local)\n```\n\n### 5.3 — Install Specific Skills\n\n```\n/skills install <name>    # Install from registry\n/skills list              # List available\n/skills search <query>    # Search registry\n```\n\n### ✅ Verification\n\n```\n/skills list   # Should show installed skills with counts\n```\n\n---\n\n## Phase 6: Permissions Configuration\n\n**Trigger**: Permission mode not configured or wrong for use case.\n\n### 6.1 — Permission Modes\n\n| Mode                | Behavior                               | Use Case                                  |\n| ------------------- | -------------------------------------- | ----------------------------------------- |\n| `default`           | Ask-first tools are refused (see note) | Normal development (recommended)          |\n| `acceptEdits`       | Auto-allow edits, ask for other tools  | Active coding sessions                    |\n| `plan`              | Plan-only, no tool execution           | Design & architecture work                |\n| `auto`              | A classifier rules on every call       | Long unattended runs you still want gated |\n| `bypassPermissions` | Skip all checks                        | ⚠️ Only for fully trusted codebases       |\n\n**Note on `default`**: Mipham Code has no interactive approval prompt, so \"ask\"\nmeans the call is **refused** with a message naming the mode — it is not queued\nfor your answer. That makes `default` the strictest _usable_ mode for Bash and\nfile writes; `auto` is the mode that lets gated calls proceed without a human,\nby having a classifier rule on each one.\n\n**What `auto` actually gates.** Reads (Read/Grep/Glob) are never sent to the\nclassifier — gating them would make `auto` the only mode in the ladder that cannot\nopen a file without a round-trip to another model. Everything else that the static\nchain would refuse goes to the classifier, which can only **lift** a refusal: a\ndeny rule or an `ask` rule is never overridden. If the classifier cannot be reached\nor answers unusably, the call is refused (fail-closed) with a message saying the\nrefusal is _not_ a policy decision and can be retried.\n\n### 6.2 — Configure\n\nPress **Shift+Tab** to change the mode live; it cycles\n`default → acceptEdits → plan → auto` and lasts for the session only.\n`bypassPermissions` is a legal mode but is deliberately **not** on the wheel —\nit is reached by naming it in config, where the user has said what they mean.\n\nTo persist a mode, name it in `~/.mipham/config.yml`:\n\n```yaml\npermission: default\n```\n\nOr in `~/.mipham/settings.json` as `permissions.defaultMode` (the key Claude Code\nusers already have). Any mode name from the table above is accepted in either,\nincluding `bypassPermissions`.\n\nA **project-level** `.mipham/config.yml` cannot set a mode — that file arrives with\nthe code, so whoever wrote the repository would be choosing the approval gate. A\nmode found there is ignored and reported; the fix is to move the line to the user\nlevel, or to pass `--permission <mode>` for one invocation.\n\nOr via slash command:\n\n```\n/permissions           # View current settings\n/setup 5               # Permission setup wizard\n```\n\n### 6.3 — CI/CD Safety\n\nFor CI/CD environments, use the `default` mode (the daemon default): headless\nsessions never prompt, so `ask`-level tools (Bash/Write/Edit) are blocked rather\nthan auto-approved.\n\n### ✅ Verification\n\n```\n/permissions   # Should show current mode\n```\n\n---\n\n## Phase 7: Workspace Trust\n\n**Trigger**: Untrusted workspace (prompted on startup in v0.24.3+).\n\n### 7.1 — Understanding Workspace Trust\n\nWorkspace trust is a security mechanism that prevents AI from operating in untrusted directories. Trust is **hierarchical**: trusting `/Users/me/Projects` implicitly trusts all subdirectories.\n\n### 7.2 — Trust a Workspace\n\n**Interactive**: Accept the trust prompt when launching Mipham Code in a new directory.\n\n**Manual**:\n\n```\n/trust              # Show trust status\n/trust add <dir>    # Trust a directory\n/trust remove <dir> # Revoke trust\n```\n\n### 7.3 — Trust Store\n\n```\n~/.mipham/trusted-workspaces.json\n```\n\n### 7.4 — Auto-Trust for Worktrees\n\nWhen using git worktrees, Mipham Code automatically trusts worktree directories if the parent workspace is already trusted (via `EnterWorktree`).\n\n### ✅ Verification\n\n```\n/trust   # Should show \"✅ Yes\" for current directory\n```\n\n---\n\n## Phase 8: Shell & IDE Integration\n\n**Trigger**: Want terminal integration, aliases, or IDE plugins.\n\n### 8.1 — Shell Alias\n\nAdd to `~/.zshrc` or `~/.bashrc`:\n\n```bash\nalias mipham='cd ~/your-project && bun run ~/path/to/mipham-code/apps/cli/bin/mipham.ts'\n# Or if installed globally:\nalias mipham='mipham'\n```\n\n### 8.2 — VS Code Integration\n\nRun `/ide` to auto-generate `.vscode/` config files:\n\n- `settings.json` — terminal profile \"mipham\" using Bun\n- `keybindings.json` — Cmd+Esc to focus terminal, Cmd+Shift+M for new terminal\n- `extensions.json` — recommends `miphamai.mipham-code` extension\n\nTo use after generation:\n\n1. Restart VS Code (or Cmd+Shift+P → Reload Window)\n2. Open terminal: Ctrl+` or Cmd+Esc\n3. Select \"mipham\" profile from terminal dropdown\n\nInstall the VS Code extension:\n\n```bash\ncode --install-extension miphamai.mipham-code\n```\n\n### 8.3 — JetBrains Integration\n\nSettings → Tools → Terminal → Shell path → `bun run mipham`\n\n### 8.4 — Terminal Setup\n\n```\n/terminal-setup    # Shell & terminal config wizard\n/setup 6           # Shell integration (part of full wizard)\n```\n\n### ✅ Verification\n\n```bash\nwhich mipham       # Should resolve\n# In VS Code: Ctrl+` → select \"mipham\" profile\n```\n\n---\n\n## Phase 9: Full Verification\n\nRun after all configuration phases complete.\n\n### 9.1 — System Diagnostics\n\n```\n/doctor            # System diagnostics check\n```\n\n### 9.2 — End-to-End Test\n\nStart a conversation and verify:\n\n1. Model responds (not stuck on \"connecting...\")\n2. File tools work: \"read CLAUDE.md\"\n3. Bash works: \"list files in current directory\"\n4. Skills load: `/skills list`\n\n### 9.3 — Common Issues & Fixes\n\n| Symptom                   | Diagnosis                              | Fix                                              |\n| ------------------------- | -------------------------------------- | ------------------------------------------------ |\n| \"Provider not registered\" | Missing or invalid API key             | `env \\| grep API_KEY`; check key format          |\n| \"Model not found\"         | Model ID mismatch or disabled provider | `/models` to list available; `/switch` to change |\n| Slow responses            | Large model, network, or context full  | `/fast on` or switch to Flash model; `/compact`  |\n| Context full              | Too many messages in history           | `/compact` to compress; `/clear` to reset        |\n| Permission denied         | Tool blocked by permission mode        | `/permissions` to check; adjust mode             |\n| \"Workspace not trusted\"   | New directory, not yet trusted         | Accept startup prompt or run `/trust`            |\n| MCP tools not available   | Server not connected                   | `/mcp connect <name>` or check config            |\n| Update not applying       | Cached binary                          | `mipham update --force` then restart             |\n| Config changes ignored    | YAML syntax error                      | Validate with `mipham --check-config`            |\n\n### 9.4 — Get Help\n\n```\n/help              # Full command reference\n/setup             # Re-run setup wizard\n/doctor            # Run diagnostics\n```\n\nChat-based help: \"help me configure X\" or \"why isn't Y working?\"\n\n---\n\n## Quick Reference: Essential Slash Commands\n\n| Category      | Command           | Purpose                                                |\n| ------------- | ----------------- | ------------------------------------------------------ |\n| **Setup**     | `/setup`          | Full 6-step setup wizard                               |\n|               | `/setup 1`        | Initialize project (.mipham/ + MIPHAM.md + config.yml) |\n|               | `/setup 2`        | Configure providers & API keys                         |\n|               | `/setup 3`        | Choose default model                                   |\n|               | `/setup 4`        | Browse & install skills                                |\n|               | `/setup 5`        | Configure permissions                                  |\n|               | `/setup 6`        | Shell & IDE integration                                |\n| **Diagnosis** | `/doctor`         | System diagnostics                                     |\n|               | `/trust`          | Workspace trust status                                 |\n|               | `/permissions`    | Tool permission settings                               |\n| **Model**     | `/model`          | Interactive model picker (Ctrl+P)                      |\n|               | `/switch`         | Switch provider                                        |\n|               | `/models`         | List available models                                  |\n| **Session**   | `/clear`          | Reset conversation                                     |\n|               | `/compact`        | Compress context                                       |\n|               | `/rename`         | Rename session                                         |\n| **Workflow**  | `/plan`           | Enter plan mode                                        |\n|               | `/review`         | Code review                                            |\n|               | `/todos`          | Task list                                              |\n| **IDE**       | `/ide`            | Generate VS Code integration files                     |\n|               | `/terminal-setup` | Shell & terminal config                                |\n| **Skills**    | `/skills list`    | List installed skills                                  |\n|               | `/skills search`  | Search skill registry                                  |\n|               | `/skills install` | Install a skill                                        |\n\n---\n\n## Post-Setup: What to Do Next\n\nAfter configuration is verified:\n\n1. **Initialize your project**: \"help me understand this codebase\"\n2. **Set up CLAUDE.md**: `/init` to generate project documentation for the AI\n3. **Install relevant skills**: `/setup 4` or `/skills search`\n4. **Configure MCP servers**: `/mcp connect` for external tool integration\n5. **Start coding**: Just start a conversation — the AI will use tools and skills automatically\n" },
   { type: 'standard', raw: "---\nname: research\ndescription: Deep research against primary sources, executed as a background agent. Collects findings into a single cited Markdown file. Use for investigation that requires reading official docs, source code, specs, or first-party APIs — not secondary summaries.\nversion: 1.0.0\nuser-invocable: true\nallowed-tools:\n  - WebSearch\n  - WebFetch\n  - Agent\n  - Bash\n  - Write\n  - Read\n---\n\n# Research — Background Deep Research\n\n融合 Mipham web-search v3.0（查询构建+验证）+ Matt Pocock research（后台代理+一手来源+Markdown 报告）。\n\n## When to Use\n\n- \"Research X for me\"\n- \"Find out everything about Y from primary sources\"\n- \"Investigate Z and write up findings\"\n- Any question where googling + reading multiple sources is the right answer\n\n## When NOT to Use\n\n- Quick fact lookup → use `/web-search` directly\n- Question answerable from code already in context\n- Pure logic/algorithmic question\n\n---\n\n## Phase 0: Route\n\n```\nResearch task is...\n├── Quick (1-2 sources, immediate answer)?\n│   └── → Use web-search skill directly (Phase 0-4)\n│\n├── Deep (multiple sources, needs synthesis)?\n│   └── → THIS SKILL — background agent\n│\n└── Login-walled / SPA-only sources?\n    └── → web-access skill (ComputerUse browser)\n```\n\n---\n\n## Phase 1: Spin Up Background Agent\n\nLaunch a **background agent** to do the heavy reading, so you keep working while it researches.\n\nThe agent's instructions:\n\n```\nYou are a research agent. Your task:\n\n1. Investigate the question against PRIMARY SOURCES ONLY:\n   - Official documentation (docs.*.com, *.org)\n   - Source code repositories (GitHub, GitLab)\n   - Technical specifications (RFCs, standards)\n   - First-party API references\n   - NOT: blog posts, Medium articles, forum threads, secondary summaries\n\n2. For every claim, follow it back to the source that owns it.\n   If a secondary source makes a claim, find the primary source and cite that.\n\n3. Use WebSearch to find sources.\n   Use WebFetch to deep-read promising pages.\n   Cross-reference critical claims across 2+ independent primary sources.\n\n4. Write findings to a SINGLE Markdown file.\n   - Cite every claim with its primary source URL\n   - Distinguish between facts (needs citation) and reasoning (your own)\n   - Flag outdated content (\"article from 2024, may be stale\")\n   - Note if a source is official docs vs community\n\n5. Save the file where the repo already keeps such notes.\n   Match existing conventions. If none exist, put it in docs/research/.\n```\n\n---\n\n## Phase 2: Report Format\n\nThe agent writes findings in this structure:\n\n```markdown\n# [Research Topic]\n\n**Date**: YYYY-MM-DD\n**Sources**: N primary, M cross-references\n\n## Key Findings\n\n- [Finding 1] — [Source](URL)\n- [Finding 2] — [Source](URL)\n\n## Detailed Analysis\n\n### [Subtopic A]\n\n[Claim and citation]\n\n### [Subtopic B]\n\n[Claim and citation]\n\n## Source Evaluation\n\n| Source      | Type          | Authority | Notes                 |\n| ----------- | ------------- | --------- | --------------------- |\n| [Name](URL) | Official docs | High      | Current as of YYYY-MM |\n| [Name](URL) | Source code   | High      | Tag vX.Y.Z            |\n\n## Open Questions\n\n- [Question 1]\n- [Question 2]\n\nSources:\n\n- [Title](URL) — brief note\n```\n\n---\n\n## Phase 3: Review\n\nWhen the background agent completes:\n\n1. Read the output file\n2. Spot-check: did it follow the chain back to primary sources?\n3. Flag any claims that need further verification\n4. Surface uncertainties to the user\n\n---\n\n## Research Quality Checklist\n\n- [ ] Every factual claim has a primary source citation\n- [ ] At least one critical claim is cross-referenced (2+ sources)\n- [ ] Source type is clearly identified (official docs / source code / spec / community)\n- [ ] Outdated content is flagged with publication year\n- [ ] Reasoning vs facts are clearly distinguished\n- [ ] File saved in repo-appropriate location\n" },
   { type: 'standard', raw: "---\nname: safe-coding\ndescription: Safe coding rules for code generation — validate external/user input before use and throw RangeError on invalid input\nversion: 1.0.0\n---\n\n# Safe Coding\n\n处理外部/用户输入前必须校验：`null`、`undefined`、空字符串、格式非法时，抛出 `RangeError`，消息为 `'invalid input'`。\n" },
   { type: 'standard', raw: "---\nname: security-review\ndescription: Security audit skill — vulnerability scanning, OWASP Top 10, secrets detection, supply chain analysis, and compliance checking\nversion: 1.0.0\n---\n\n# Security Review\n\nComprehensive security audit for codebases. Covers vulnerability detection, compliance, and hardening recommendations.\n\n## Audit Checklist\n\n### 1. Secrets & Credentials\n\n- [ ] No hardcoded API keys, tokens, or passwords in source files\n- [ ] `.env` and `*.pem` files in `.gitignore`\n- [ ] API keys use environment variables or secret managers\n- [ ] No credentials in git history (check `git log -p`)\n- [ ] CI/CD secrets stored securely (not in workflow files)\n\n### 2. OWASP Top 10\n\n- [ ] **Injection**: SQL, NoSQL, OS command, LDAP injection points\n- [ ] **Broken Authentication**: Weak password policies, missing MFA\n- [ ] **Sensitive Data Exposure**: Unencrypted PII, missing TLS\n- [ ] **XXE**: XML external entity processing\n- [ ] **Broken Access Control**: Missing authorization checks\n- [ ] **Security Misconfiguration**: Default credentials, verbose errors\n- [ ] **XSS**: Reflected, stored, DOM-based cross-site scripting\n- [ ] **Insecure Deserialization**: Untrusted data deserialization\n- [ ] **Using Vulnerable Components**: Outdated dependencies with CVEs\n- [ ] **Insufficient Logging**: Missing audit trails for auth events\n\n### 3. Supply Chain\n\n- [ ] All dependencies have known licenses (no copyleft/GPL)\n- [ ] No dependencies with critical CVEs\n- [ ] Lock files committed (pnpm-lock.yaml, package-lock.json)\n- [ ] Dependency update policy in place\n- [ ] SBOM (Software Bill of Materials) available\n\n### 4. Network & API Security\n\n- [ ] TLS 1.3 enforced for all external communications\n- [ ] API endpoints have rate limiting\n- [ ] CORS configured with explicit origins (not `*`)\n- [ ] SSRF protections in place (URL validation, IP filtering)\n- [ ] WebSocket connections use WSS\n- [ ] GraphQL endpoints have query depth limits\n\n### 5. File System & Path Security\n\n- [ ] Path traversal protections (no `../../../etc/passwd`)\n- [ ] File upload validation (type, size, content inspection)\n- [ ] Symlink attacks prevented\n- [ ] Sensitive directories blocked (`/etc`, `/proc`, `/sys`)\n- [ ] Temporary files cleaned up after use\n\n### 6. Code-Level Security\n\n- [ ] No `eval()` or `Function()` with user input\n- [ ] No `child_process.exec()` with unsanitized input\n- [ ] Regex patterns safe from ReDoS\n- [ ] Prototype pollution prevented\n- [ ] No `dangerouslySetInnerHTML` without sanitization (React)\n- [ ] SQL queries use parameterized statements\n\n### 7. Authentication & Sessions\n\n- [ ] Passwords hashed with bcrypt/argon2 (not MD5/SHA1)\n- [ ] Session tokens use `httpOnly`, `secure`, `SameSite=Strict`\n- [ ] JWT tokens have reasonable expiration\n- [ ] Account lockout after failed attempts\n- [ ] Password reset tokens expire and are single-use\n\n### 8. Data Protection\n\n- [ ] PII data encrypted at rest (AES-256-GCM)\n- [ ] Data encrypted in transit (TLS 1.3)\n- [ ] Logs do not contain sensitive data\n- [ ] Database backups encrypted\n- [ ] Data retention policies defined\n\n### 9. Infrastructure\n\n- [ ] Infrastructure as Code (Terraform/Pulumi) used\n- [ ] Cloud resources not publicly exposed unless intended\n- [ ] Security groups / firewalls restrict inbound traffic\n- [ ] Container images scanned for vulnerabilities\n- [ ] Kubernetes pods run as non-root\n\n### 10. Logging & Monitoring\n\n- [ ] Authentication events logged\n- [ ] Failed access attempts logged and alerted\n- [ ] Structured logging format (JSON)\n- [ ] No PII in log messages\n- [ ] Alert thresholds configured for critical events\n\n## Report Format\n\n```\nSecurity Review Report\n======================\nDate: YYYY-MM-DD\nSeverity: Critical | High | Medium | Low\n\nFinding #N: [Title]\nSeverity: Critical/High/Medium/Low\nLocation: file:line\nDescription: [What was found]\nRisk: [What could happen]\nFix: [How to resolve]\n```\n\n## Compliance Standards\n\n- OWASP ASVS Level 2\n- PCI DSS (if handling payment data)\n- GDPR (if handling EU personal data)\n- SOC 2 Type II\n- ISO 27001\n" },

package/src/ui/app.tsx

@@ -46,6 +46,7 @@ function contextUsagePct(engine: QueryEngine | RemoteEngine): number | undefined
   return Math.round((ctx.getEstimatedTokens() / max) * 100)
 }
 import { AgentViewDashboard } from '../agent-view/dashboard'
+import { AgentSessionView } from '../agent-view/session-view'
 import type { AgentViewManager } from '../agent-view/agent-view-manager'
 import { WorkflowProgress } from './workflow-progress.js'
 import { GoalProgress } from './goal-progress.js'
@@ -318,6 +319,11 @@ export function App({
   }, [])
 
   const [agentViewOpen, setAgentViewOpen] = useState(false)
+  // Non-null when the dashboard's Enter ("attach") picked a session to read.
+  // It replaces the chat panel — the transcript on screen is the session's, not
+  // this conversation's, so leaving the input bar visible would invite typing
+  // into a buffer that goes somewhere else entirely.
+  const [attachedSessionId, setAttachedSessionId] = useState<string | null>(null)
   const [apiKeyPrompt, setApiKeyPrompt] = useState<{
     providerId: string
     modelId: string
@@ -335,6 +341,14 @@ export function App({
   const [permissionMode, setPermissionMode] = useState<PermissionMode>(() =>
     livePermissionMode(engine.getPermission()),
   )
+  // 远端 attach：闸门在 daemon 上，而它的答案是**异步**来的（组织级限制会在那边把请求
+  // 静默钳小）。按键不等于渲染，所以只靠上行的 `useState` 初始化 + 按键回读，页脚会永远
+  // 停在钳制前的那一档 —— 报得比实际宽。本地引擎没有这条订阅：它的 `getMode()` 在
+  // `setMode` 返回时就已经是钳后值。
+  useEffect(() => {
+    if (!('onPermissionModeChange' in engine)) return
+    return engine.onPermissionModeChange((mode) => setPermissionMode(mode))
+  }, [engine])
   const abortRef = useRef<AbortController | null>(null)
   // Monotonic turn id — lets a stale turn's finally() skip resetting shared UI
   // state (isLoading/abortRef/progress) after a newer turn has already started.
@@ -1264,9 +1278,24 @@ export function App({
         {agentViewOpen && agentViewManager ? (
           <AgentViewDashboard
             manager={agentViewManager}
-            onAttach={() => {}}
+            // Enter used to be wired to a no-op here, so `attach` — the key the
+            // footer advertises — did nothing observable. It now hands the
+            // session to the read-only view below; Esc there comes back here.
+            onAttach={(session) => {
+              setAttachedSessionId(session.id)
+              setAgentViewOpen(false)
+            }}
             onExit={() => setAgentViewOpen(false)}
           />
+        ) : attachedSessionId && agentViewManager ? (
+          <AgentSessionView
+            manager={agentViewManager}
+            sessionId={attachedSessionId}
+            onDetach={() => {
+              setAttachedSessionId(null)
+              setAgentViewOpen(true)
+            }}
+          />
         ) : (
           <>
             {/* Chat panel */}

package/src/ui/commands.ts

@@ -389,6 +389,16 @@ const contextCmd: CommandHandler = (ctx) => {
   }
 }
 
+/**
+ * The mode the gate is actually enforcing. `ctx.config.permission` is only one of
+ * the doors — the Shift+Tab wheel, an org `maxAllowedMode` clamp and the user's
+ * `settings.json` all move the live value — so a report that prints the config
+ * value can name a different mode than the one refusing the calls.
+ */
+function liveMode(ctx: CommandContext): string {
+  return ctx.engine.getPermission().getMode()
+}
+
 const statusCmd: CommandHandler = async (ctx) => {
   const t = resolveT(ctx)
   const c = ctx.engine.getContext()
@@ -411,7 +421,7 @@ const statusCmd: CommandHandler = async (ctx) => {
       ${t('commands.status.messages')}   ${c.getMessages().length}
       ${t('commands.status.tokens')}     ~${c.getEstimatedTokens().toLocaleString()} / ${c.getMaxTokens().toLocaleString()}
       ${t('commands.status.tools')}      ${tools.size} ${t('commands.status.loaded')}
-      ${t('commands.status.permission')} ${ctx.config.permission}
+      ${t('commands.status.permission')} ${liveMode(ctx)}
 
       ${t('commands.status.system_title')}
       ${t('commands.status.platform')}   ${process.platform} ${process.arch}
@@ -3211,7 +3221,7 @@ const doctorCmd: CommandHandler = async (ctx) => {
     '',
     t('commands.doctor.config_section'),
     `Provider     ${ctx.providerId} / ${ctx.modelId}`,
-    `Permission   ${ctx.config.permission}`,
+    `Permission   ${liveMode(ctx)}`,
     `Providers    ${ctx.config.providers.length} configured (${ctx.config.providers.filter((p) => p.status !== 'upcoming').length} active)`,
     '',
     t('commands.doctor.session_section'),
@@ -3727,7 +3737,7 @@ const statsCmd: CommandHandler = (ctx) => {
     t('commands.stats.tools', { count: String(tools.size) }),
     t('commands.stats.provider', { provider: ctx.providerId }),
     t('commands.stats.model', { model: ctx.modelId }),
-    t('commands.stats.permission', { permission: ctx.config.permission }),
+    t('commands.stats.permission', { permission: liveMode(ctx) }),
     '',
     t('commands.stats.usage', { pct: ((tokens / c.getMaxTokens()) * 100).toFixed(1) }),
   ]
@@ -5200,10 +5210,14 @@ Background agents appear in the Agent View dashboard (/agents).`,
   // wrote a dashboard entry and reported success — the prompt was never handed
   // to a model, and the row sat at `working` forever.
   const bgReg = (await import('../agent/background-registry')).getBackgroundAgentRegistry()
-  bgReg.spawn(
+  // Keep the registry's id on the row: it is the only handle that can stop the
+  // run. `AgentViewManager.kill()` flips a status label and nothing else, so a
+  // Ctrl+X that held no task id would discard the row and leave the agent
+  // running with no way to reach it again.
+  session.taskId = bgReg.spawn(
     prompt,
     'general',
-    async (_signal) => {
+    async (signal) => {
       const { SubAgent } = await import('../agent/sub-agent')
       const sa = new SubAgent(
         ctx.engine.getRegistry(),
@@ -5216,7 +5230,10 @@ Background agents appear in the Agent View dashboard (/agents).`,
       try {
         // The prompt came from the user typing `/bg …`, so it stays unframed —
         // unlike a workflow script's computed prompt.
-        const result = await sa.execute(prompt, 'bg: ' + prompt.slice(0, 60), { type: 'general' })
+        const result = await sa.execute(prompt, 'bg: ' + prompt.slice(0, 60), {
+          type: 'general',
+          signal,
+        })
         agentViewManager.addMessage(session.id, {
           role: 'assistant',
           content: result || '(no output)',
@@ -5329,10 +5346,10 @@ const forkCmd: CommandHandler = async (ctx, args) => {
   session.kind = 'forked'
 
   const bgReg = (await import('../agent/background-registry')).getBackgroundAgentRegistry()
-  bgReg.spawn(
+  session.taskId = bgReg.spawn(
     prompt,
     'general',
-    async (_signal) => {
+    async (signal) => {
       const { SubAgent } = await import('../agent/sub-agent')
       const sa = new SubAgent(
         ctx.engine.getRegistry(),
@@ -5343,32 +5360,54 @@ const forkCmd: CommandHandler = async (ctx, args) => {
         ctx.engine.getLlm(),
       )
       const parentContext = ctx.engine.getContext()
-      const result = await sa.execute(prompt, 'fork: ' + prompt.slice(0, 60), {
-        worktreePath: wtPath,
-        inheritContext: { messages: parentContext.getMessages() },
-      })
+      // The row has to come back from `working` on both outcomes: the fork
+      // executor used to return its summary to the registry and never touch the
+      // session, so a finished (or crashed) fork stayed `working` on the
+      // dashboard for the life of the process — the same lie `/bg` already
+      // closes on its own path.
       try {
-        const { execSync: ex } = await import('node:child_process')
-        ex(`git -C ${wtPath} add -A`, { stdio: 'ignore', timeout: 10_000 })
-        const st = ex(`git -C ${wtPath} status --porcelain`, { encoding: 'utf-8', timeout: 10_000 })
-        if (st.trim()) {
-          ex(`git -C ${wtPath} commit -m "feat: ${prompt.slice(0, 60)}\n\n${COAUTHOR_TRAILER}"`, {
-            stdio: 'ignore',
+        const result = await sa.execute(prompt, 'fork: ' + prompt.slice(0, 60), {
+          worktreePath: wtPath,
+          inheritContext: { messages: parentContext.getMessages() },
+          signal,
+        })
+        try {
+          const { execSync: ex } = await import('node:child_process')
+          ex(`git -C ${wtPath} add -A`, { stdio: 'ignore', timeout: 10_000 })
+          const st = ex(`git -C ${wtPath} status --porcelain`, {
+            encoding: 'utf-8',
             timeout: 10_000,
           })
-          ex(`git push origin ${branch}`, { stdio: 'ignore', timeout: 30_000 })
+          if (st.trim()) {
+            ex(`git -C ${wtPath} commit -m "feat: ${prompt.slice(0, 60)}\n\n${COAUTHOR_TRAILER}"`, {
+              stdio: 'ignore',
+              timeout: 10_000,
+            })
+            ex(`git push origin ${branch}`, { stdio: 'ignore', timeout: 30_000 })
+          }
+        } catch {
+          /* best-effort */
         }
-      } catch {
-        /* best-effort */
+        const summary = [
+          `## Fork done: ${prompt}`,
+          '',
+          `Branch: \`${branch}\``,
+          `Worktree: \`${wtPath}\``,
+          '',
+          result || '(no output)',
+        ].join('\n')
+        agentViewManager.addMessage(session.id, { role: 'assistant', content: summary })
+        agentViewManager.updateStatus(session.id, 'completed')
+        return summary
+      } catch (err) {
+        const message = err instanceof Error ? err.message : String(err)
+        agentViewManager.addMessage(session.id, {
+          role: 'assistant',
+          content: `Fork failed: ${message}`,
+        })
+        agentViewManager.updateStatus(session.id, 'failed')
+        throw err
       }
-      return [
-        `## Fork done: ${prompt}`,
-        '',
-        `Branch: \`${branch}\``,
-        `Worktree: \`${wtPath}\``,
-        '',
-        result || '(no output)',
-      ].join('\n')
     },
     'forked',
   )