# EP12 Website Draft

## Goal

Show GitHub Actions as the release automation layer, not as a magical deployment switch.

## Hero

**Claude Code Deep Dive**

One sentence:
GitHub Actions belongs in the automation plane when the team wants repeatable validation and release steps that stay visible in the repo.

## Page Structure

1. hero summary
2. automation-plane map
3. Actions vs hooks comparison
4. release-flow experiment
5. minimum viable pipeline pattern
6. official-doc links

## Interactive Blocks

### 1. Automation Plane Map

Show GitHub Actions next to hooks and local scripts in the five-layer model.

### 2. Release Flow Switcher

Let the reader switch between:

- local script
- hook
- GitHub Action
- manual release

The page should explain what gets automated and what remains human-owned.

### 3. CI Gate Demo

Show a simple release path with:

- validation
- packaging
- release note
- publish gate

### 4. Comparison Table

Compare these pairs:

- GitHub Actions vs hooks
- GitHub Actions vs local scripts
- automation plane vs control plane

Each row should answer:

- what it is
- when it runs
- what it can control
- what it cannot guarantee

## Minimum Viable UX

- release-tooling aesthetic, not a generic dashboard
- clear status signaling
- mobile-safe text and checklist blocks
- one obvious path from commit to release

## Teaching Rules

- Every block must map back to the five-layer model.
- Every block must show one failure mode.
- Every block must connect automation to the acceptance gate.

## Official Links

- memory
- settings
- hooks
- sub-agents
- GitHub Actions

## Exit Outcome

The reader should leave knowing where GitHub Actions fits, what it should automate, and where the human still has to own the release.