> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# hotfix preset

> hotfix is the lightweight bug-fix preset: open -> build -> verify -> archive, skipping brainstorming and full planning while keeping recovery, root-cause checks, verification, and archive.

`hotfix` is a lightweight Comet preset for fixing a clear bug. It runs `open -> build -> verify -> archive`, skips full brainstorming and planning, but still keeps OpenSpec state, **root-cause elimination checks**, verification, and archive.

hotfix is not “no process.” It reduces up-front design cost while preserving recovery, verification, and traceability.

<p align="center">
  <img src="https://mintcdn.com/comet-bb5f5294/vM44yjOkcpkEH_kN/assets/hotfix-preset-illustrations/01-hotfix-repair-clinic.png?fit=max&auto=format&n=vM44yjOkcpkEH_kN&q=85&s=2a8a471b083bee62a43409b902e62781" alt="Xiaoyu repairs a bug at a hotfix desk, checks the root cause, applies the smallest patch, verifies, archives, and marks the scope as unchanged" width="800" data-path="assets/hotfix-preset-illustrations/01-hotfix-repair-clinic.png" />
</p>

<p align="center">
  hotfix is faster because the design overhead is lower, not because verification and archive
  disappear.
</p>

<Tip>
  Normally you only need <code>/comet</code>. When project configuration selects Classic, the
  internal <code>/comet-classic</code> router recognizes a request to fix existing broken behavior,
  prefers hotfix, and invokes <code>/comet-hotfix</code>. Use the preset command directly only for
  manual control.
</Tip>

## When to use it

Use hotfix when all of these are true:

* You are fixing existing behavior.
* You are not adding a new capability.
* You are not changing public APIs, schemas, or architecture.
* The scope is predictable.

Do not use hotfix for cross-module redesign, database schema changes, new capabilities, public API changes, or product design discussion. If the fix hits an upgrade signal, Comet pauses and asks whether to continue hotfix or upgrade to full.

## Relationship to full and tweak

| Dimension     | hotfix                             | full                                         | tweak                              |
| ------------- | ---------------------------------- | -------------------------------------------- | ---------------------------------- |
| Goal          | Fix a bug                          | New feature, architecture, large requirement | Adjust behavior or content         |
| Flow          | open -> build -> verify -> archive | open -> design -> build -> verify -> archive | open -> build -> verify -> archive |
| Brainstorming | Skipped                            | Required                                     | Skipped                            |
| Design Doc    | Not required                       | Required                                     | Not required                       |
| Delta spec    | Exception only                     | Normal                                       | First-class artifact               |
| Build style   | Direct task loop                   | Selected during build                        | OpenSpec apply                     |

## Flow

```mermaid theme={null}
flowchart TD
    Start["Bug description"] --> S1["Fast open\nminimal OpenSpec artifacts"]
    S1 --> S2["Direct build\nbuild_mode: direct"]
    S2 --> Esc{"Upgrade signal?"}
    Esc -->|yes| Stop["Pause: continue hotfix or upgrade full"]
    Esc -->|no| S3["Root-cause elimination check"]
    Stop -->|continue| S3
    Stop -->|upgrade| Up["preset-escalate -> design"]
    S3 --> Root{"Root cause gone?"}
    Root -->|no| S2
    Root -->|yes| S4["Verify"]
    S4 --> V{"Pass?"}
    V -->|no| Fix["Verification failure decision"]
    Fix --> S2
    V -->|yes| S5["Archive after confirmation"]
```

## Default state

`comet-state init <name> hotfix` defaults to:

| Field         | Default                       |
| ------------- | ----------------------------- |
| `build_mode`  | `direct`                      |
| `tdd_mode`    | `direct`                      |
| `review_mode` | `off`                         |
| `isolation`   | `null` until the entry choice |
| `verify_mode` | `light`                       |

At entry, hotfix pauses once and asks you to explicitly keep the current branch, create a branch, or create a worktree; it no longer silently selects an isolation mode. The confirmed `isolation` and `bound_branch` describe the real execution workspace, and later accidental branch switches are blocked. `tdd_mode: direct` skips Red-Green-Refactor but still requires relevant tests and regression evidence.

## Root-cause check

This is hotfix-specific. Before build exits, Comet checks that the proposal's described root cause has actually been removed. If not, it stays in build and continues fixing.

## Upgrade signals

Comet pauses when it sees qualitative signals such as cross-module coordination, new capability, schema change, new public API, or deep architecture issue. File-count thresholds are tripwires for user confirmation, not automatic full-workflow upgrades.

Upgrade through the legal transition:

```bash theme={null}
node "$COMET_STATE" transition <name> preset-escalate
```

This switches the workflow to full and returns to design without discarding existing artifacts.

## Recovery

Hotfix is idempotent. After interruption, run `/comet`. When configuration selects Classic, the internal `/comet-classic` router reads `.comet.yaml` and returns to `/comet-hotfix` when the change is in `phase: build`.

## Next steps

* [tweak preset](/en/presets/tweak)
* [Auto-transition](/en/concepts/auto-transition)
* [Decision points](/en/concepts/decision-points)
* [Verify phase](/en/phases/verify)