# Architecture Diagram

How dsh-stage-gate works: the agent calls four model tools; gate state lives
in an in-memory GateStore scoped per agent session; **no custom session events
are written** (see the [bug report](BUG-2026-08-17-session-log-pollution.md)
for why).

```mermaid
graph TD
    A[Agent / LLM] -->|调用| B[gate_open]
    A -->|调用| C[gate_check]
    A -->|调用| D[gate_list]
    A -->|调用| E[gate_close]
    B --> F[GateStore<br/>in-memory · per-session]
    C --> F
    D --> F
    E --> F
    F --> G[状态机<br/>open → in_review → passed/blocked → closed]
    B -.✗ 不写入.-> H[(Session log)]
    C -.✗ 不写入.-> H
    D -.✗ 不写入.-> H
    E -.✗ 不写入.-> H
    style F fill:#eef2ff,stroke:#4f46e5
    style G fill:#f0fdf4,stroke:#16a34a
    style H fill:#fef2f2,stroke:#dc2626
```

## Key points

- **Four model-facing tools**: `gate_open`, `gate_check`, `gate_list`, `gate_close`.
- **In-memory, per-session** state: `GateStore` keyed by agent session id, then gate id.
- **No session-log pollution**: the plugin writes no custom `gate/*` events, so
  sessions always reload cleanly after a harness restart.
- **Lifecycle**: `open → in_review → passed/blocked → closed` derived from the
  full acceptance item list on each check.