From 90d369d91d8305b13f38b924d9a2738a404088b4 Mon Sep 17 00:00:00 2001 From: Thomas Kosiewski Date: Fri, 5 Jun 2026 12:07:48 +0200 Subject: [PATCH] docs(README): simplify positioning, add use cases, drop ROADMAP Lead the README with a plain "like Playwright, but for terminal apps" analogy and a "What you'd use it for" section so non-developers grasp it in one read. Surface the read-only dashboard as a first-class capability, make the real PNG/WebM visual-proof edge explicit, and fix stale 0.2.x version text (now 0.3.0). Delete ROADMAP.md and remove its now-dangling links from the active docs (AGENTS.md, RELEASE.md, docs/, design/). Frozen history under design/archive/ and dogfood/ is left untouched. Change-Id: Iad61eed814e24ff75eb3e77e376f0a56eaceac62 Co-Authored-By: Claude Opus 4.8 (1M context) Signed-off-by: Thomas Kosiewski --- AGENTS.md | 2 +- README.md | 77 ++++++++++--------- RELEASE.md | 2 +- ROADMAP.md | 39 ---------- .../03-rendering-and-artifacts.md | 4 +- design/ARCHITECTURE.md | 4 +- design/README.md | 1 - docs/CONTRIBUTING.md | 2 +- docs/README.md | 1 - docs/RELEASE-PROCESS.md | 11 ++- 10 files changed, 54 insertions(+), 89 deletions(-) delete mode 100644 ROADMAP.md diff --git a/AGENTS.md b/AGENTS.md index 04e0afa2..b1e81fe9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -47,7 +47,7 @@ Session state is stored under `~/.agent-tty` by default. In tests and automation - `src/export/asciicast.ts` and `src/export/webm.ts` — recording export logic. - `src/util/assert.ts` — shared fail-fast assertion helpers. - `design/ARCHITECTURE.md` — stable architecture and product intent overview. -- `ROADMAP.md` and `RELEASE.md` — shipped scope vs deferred scope at the repo root. +- `RELEASE.md` — supported scope at the repo root. - `dogfood/README.md` and `dogfood/CATALOG.md` — proof-bundle navigation and reviewer-facing validation artifacts. ## Important directories diff --git a/README.md b/README.md index 0d25c64c..f0e5cf2a 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,8 @@ # agent-tty -Drive and inspect long-lived terminal sessions from the CLI, with reviewable snapshots, screenshots, and recordings. +Give your AI agent a real terminal it can drive, and get back reviewable snapshots, screenshots, and recordings of everything it did. + +> It's like Playwright, but for terminal apps instead of web pages. [![npm](https://img.shields.io/npm/v/agent-tty)](https://www.npmjs.com/package/agent-tty) [![CI](https://github.com/coder/agent-tty/actions/workflows/ci.yml/badge.svg)](https://github.com/coder/agent-tty/actions/workflows/ci.yml) @@ -9,13 +11,17 @@ Drive and inspect long-lived terminal sessions from the CLI, with reviewable sna ![agent-tty: drive a terminal session and watch it live in the dashboard](./assets/hero.gif) -`agent-tty` keeps a real PTY-backed terminal session alive across separate CLI invocations. You `run` a command in it, `wait` for the screen to reach a condition instead of sleeping, then capture what happened as a semantic text snapshot, a PNG screenshot, an asciinema-compatible `.cast`, or a WebM. The recording is the point: a human — or an AI coding agent — can replay and verify exactly what the terminal did, instead of trusting a blind script. +Tools like `tmux` or `screen` help _you_ manage your own terminal windows. `agent-tty` is for handing a real, long-lived terminal to an AI coding agent, so it can run commands, drive interactive apps like `nvim` or `htop`, and read the screen back. Because every session is recorded, you never have to take the agent's word for what happened: you (or another agent) get a plain-text snapshot, a real screenshot, or a video of the actual screen, and can replay it to check the work. It works just as well for plain shell automation and CI smoke tests with no agent involved. + +## What you'd use it for -It started as a way to reproduce and verify TUI bug reports (see [Why it exists](#why-it-exists)), and it's equally useful for shell automation, CI smoke tests, and driving interactive CLIs. +- **Proof you can review.** An agent runs a task and attaches the screenshot, video, or replayable recording to its PR, so a human can confirm at a glance that the change really worked, instead of trusting a log. +- **A tighter feedback loop.** Tell the agent to actually _use_ the TUI it just built or fixed, then read the screen back, so it catches a broken layout itself before you ever see it. +- **Reproducing terminal bugs.** Spin up a clean, isolated terminal, reproduce a flaky TUI bug report there, hand it to an agent to attempt a fix, and verify the fix with a fresh recording. ## Quickstart -Requires Node `>=24 <27`. Screenshots and WebM export also need a Playwright Chromium install (`npx playwright install chromium`). +Requires Node `>=24 <27`. Screenshots and WebM video also need a Playwright Chromium install (`npx playwright install chromium`). ```bash npm install -g agent-tty @@ -34,7 +40,7 @@ agent-tty screenshot "$SID" --json agent-tty destroy "$SID" --json ``` -Driving an interactive TUI is the same loop with key chords and a stability wait: +Driving an interactive TUI is the same loop, with key chords and a wait for the screen to settle: ```bash agent-tty run "$SID" 'nvim --clean' --no-wait --json @@ -44,56 +50,51 @@ agent-tty screenshot "$SID" --json agent-tty record export "$SID" --format webm --json ``` -More workflows in [`docs/USAGE.md`](./docs/USAGE.md). Other install paths (tarballs, prerelease channels, source checkouts) in [`docs/INSTALL.md`](./docs/INSTALL.md). +More workflows are in [`docs/USAGE.md`](./docs/USAGE.md). Other install paths (tarballs, prerelease channels, source checkouts) are in [`docs/INSTALL.md`](./docs/INSTALL.md). ## Why not just tmux, expect, asciinema, or Playwright? Those tools are good, and you can get partway with any of them. `agent-tty` exists because driving a terminal _and_ getting reviewable evidence back is awkward with each one: -| If you reach for… | You get | What `agent-tty` adds | -| ------------------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -| `tmux` + `send-keys` / `capture-pane` | drive a pane, scrape raw bytes | a `wait`-for-condition primitive (stop sleeping and grepping), semantic snapshots, and PNG / `.cast` / WebM artifacts a process or human can review | -| `expect` | scripted input/output matching on a byte stream | a model of the _rendered screen_ (cursor, alt-screen, colors), plus shareable visual artifacts | -| `asciinema` / VHS | a recording to watch later | programmatic drive + `wait` + inspect — act on terminal state, not just record it (and it still exports asciinema-compatible `.cast`) | -| Playwright | this exact stateful loop, for browsers | the same drive → wait → inspect → snapshot loop, applied to terminals and TUIs | +| If you reach for… | You get | What `agent-tty` adds | +| ------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tmux` + `send-keys` / `capture-pane` | drive a pane, scrape raw bytes | a `wait`-for-condition primitive (stop sleeping and grepping), semantic snapshots, and PNG / `.cast` / WebM artifacts a process or human can review | +| `expect` | scripted input/output matching on a byte stream | a model of the _rendered screen_ (cursor, alt-screen, colors), plus shareable visual artifacts | +| `asciinema` / VHS | a recording to watch later | programmatic drive + `wait` + inspect, so you act on terminal state instead of only recording it (and it still exports asciinema-compatible `.cast`) | +| Playwright | this exact stateful loop, for browsers | the same drive → wait → inspect → snapshot loop, applied to terminals and TUIs | + +One practical difference worth calling out: `agent-tty` produces real **PNG screenshots and WebM video** of the rendered screen, not just text or an asciicast. That means the proof an agent attaches to a PR is something a human can glance at inline, with no special player. `agent-tty` is an automation-and-inspection layer, not a tmux replacement. +## Watch sessions live + +`agent-tty dashboard` opens a read-only, interactive view that lists your sessions and live-mirrors the selected one, so you can watch what your agents are doing in their shells (for example in a `tmux` split). It reads the append-only event log as its source of truth and never interrupts the running session. It needs the `libghostty-vt` renderer and an interactive terminal; machine-readable listing stays available via `list --json`. + ## How it works ```text agent-tty CLI → per-session host → PTY + append-only event log → Ghostty renderer → artifacts ``` -Every session is backed by a real PTY (`node-pty`) and an append-only event log. The log is the source of truth, so snapshots, screenshots, and recordings can be regenerated deterministically by replaying it — even after the session has exited. +Every session is backed by a real PTY (`node-pty`) and an append-only event log. The log is the source of truth, so snapshots, screenshots, and recordings can be regenerated deterministically by replaying it, even after the session has exited. Rendering uses Ghostty's terminal engine through two interchangeable backends (`--renderer`): -- **`libghostty-vt`** — Ghostty's native VT engine, bound into Node. Fast, browser-free semantic snapshots and `wait` checks. +- **`libghostty-vt`** — Ghostty's native VT engine, bound into Node. Fast, browser-free semantic snapshots and `wait` checks. Also powers the dashboard. - **`ghostty-web`** (default) — a headless web build of Ghostty driven by Playwright/Chromium. Adds pixel PNG screenshots and WebM video. -`ghostty-web` is a _reference_ renderer: it shows what a pinned Ghostty build draws, not a pixel-for-pixel guarantee of any particular native terminal window. That tradeoff is deliberate — the renderer sits behind an adapter, so native backends can be added later without changing the CLI contract. - -## Why it exists - -I maintain [`coder/claudecode.nvim`](https://github.com/coder/claudecode.nvim) and was drowning in issues and PRs I couldn't easily reproduce — Neovim is a TUI, and "reproduce this, configure that, screenshot the result" is painful to script with sleeps and `capture-pane`. `agent-tty` lets me spin up an isolated, reproducible terminal environment, hand it to a coding agent to attempt a fix, and then verify the fix with a fresh session and a recording I can actually look at. +`ghostty-web` is a _reference_ renderer: it shows what a pinned Ghostty build draws, not a pixel-for-pixel guarantee of any particular native terminal window. That tradeoff is deliberate. The renderer sits behind an adapter, so native backends can be added later without changing the CLI contract. -A colleague then used `agent-tty` to build an experimental TUI for Coder agents almost entirely by letting coding agents drive it — checking the screenshots and recordings it produced instead of watching over their shoulder. That's the loop it's built for: **an agent acts, `agent-tty` captures reviewable evidence, a human (or another agent) verifies.** +## Where it came from -## Command surface - -Global flags: `--home ` (or `AGENT_TTY_HOME`; defaults to `~/.agent-tty`), `--renderer ` (or `AGENT_TTY_RENDERER`), `--json`, `--timeout-ms `, `--no-color`, `--log-level `, `--profile `. +I maintain [`coder/claudecode.nvim`](https://github.com/coder/claudecode.nvim) and was drowning in issues and PRs I couldn't easily reproduce. Neovim is a TUI, and "reproduce this, configure that, screenshot the result" is painful to script with sleeps and `capture-pane`. `agent-tty` lets me spin up an isolated, reproducible terminal, hand it to a coding agent to attempt a fix, and then verify the fix with a fresh session and a recording I can actually look at. -- **Environment:** `version`, `doctor`, `skills list|get|path` -- **Lifecycle:** `create`, `list`, `inspect`, `destroy`, `gc` -- **Input & control:** `run`, `type`, `paste`, `send-keys`, `resize`, `signal`, `mark` -- **Observe & capture:** `wait`, `snapshot`, `screenshot`, `record export` - -Every user-facing command takes `--json` and returns a stable, machine-readable envelope. See [`docs/USAGE.md`](./docs/USAGE.md) for details and [`docs/TROUBLESHOOTING.md`](./docs/TROUBLESHOOTING.md) for renderer/environment issues. +A colleague then used `agent-tty` to build an experimental TUI for Coder agents almost entirely by letting coding agents drive it, checking the screenshots and recordings it produced instead of watching over their shoulder. That's the loop it's built for: an agent acts, `agent-tty` captures reviewable evidence, and a human (or another agent) verifies. ## Demos -Real Codex and Claude TUIs discovering the `agent-tty` skill, driving `nvim --clean`, writing a file, and exporting inner proof artifacts. (GitHub renders these as click-to-play H.264 players.) +Real Codex and Claude TUIs discovering the `agent-tty` skill, driving `nvim --clean`, writing a file, and exporting inner proof artifacts. (GitHub renders these as click-to-play players.) @@ -106,7 +107,13 @@ Real Codex and Claude TUIs discovering the `agent-tty` skill, driving `nvim --cl
-Full reproducer, transcripts, and proof bundles in [`dogfood/agent-uses-agent-tty/`](./dogfood/agent-uses-agent-tty/) and [`dogfood/CATALOG.md`](./dogfood/CATALOG.md). +Full reproducer, transcripts, and proof bundles are in [`dogfood/agent-uses-agent-tty/`](./dogfood/agent-uses-agent-tty/) and [`dogfood/CATALOG.md`](./dogfood/CATALOG.md). + +## Command surface + +Every user-facing command takes `--json` and returns a stable, machine-readable envelope. The commands cover the session lifecycle (`create`, `list`, `inspect`, `destroy`, `gc`), input and control (`run`, `type`, `paste`, `send-keys`, `resize`, `signal`, `mark`), observation and capture (`wait`, `snapshot`, `screenshot`, `record export`), the live `dashboard`, and environment checks (`version`, `doctor`, `skills`). + +See [`docs/USAGE.md`](./docs/USAGE.md) for the full flag reference and [`docs/TROUBLESHOOTING.md`](./docs/TROUBLESHOOTING.md) for renderer and environment issues. ## Agent skills @@ -121,18 +128,18 @@ See [`docs/AGENT-SKILLS.md`](./docs/AGENT-SKILLS.md). ## Status & platform support -`agent-tty` is `0.2.x` and focused on reliable, isolated, reviewable terminal/TUI automation through a stable CLI. +`agent-tty` is `0.3.0` and focused on reliable, isolated, reviewable terminal and TUI automation through a stable CLI. - Linux and macOS are tier-1; Windows is tier-2 and not CI-tested. -- Screenshots and WebM export depend on Playwright/Chromium and the `ghostty-web` backend. +- Screenshots and WebM video depend on Playwright/Chromium and the `ghostty-web` backend. - `run` is best for shell setup and command injection; it does not capture a child command's structured output or exit status. - Apache-2.0, runs entirely locally, no account or SaaS. -Deferred work (native renderers, mouse input, remote control, an MCP wrapper) is tracked in [`ROADMAP.md`](./ROADMAP.md). The supported contract is in [`RELEASE.md`](./RELEASE.md); the architecture is in [`design/ARCHITECTURE.md`](./design/ARCHITECTURE.md). +The supported contract is in [`RELEASE.md`](./RELEASE.md); the architecture is in [`design/ARCHITECTURE.md`](./design/ARCHITECTURE.md). ## Contributing -Issues and PRs welcome — see [`docs/CONTRIBUTING.md`](./docs/CONTRIBUTING.md) and the [`good first issue`](https://github.com/coder/agent-tty/labels/good%20first%20issue) / [`help wanted`](https://github.com/coder/agent-tty/labels/help%20wanted) labels. +Issues and PRs welcome. See [`docs/CONTRIBUTING.md`](./docs/CONTRIBUTING.md) and the [`good first issue`](https://github.com/coder/agent-tty/labels/good%20first%20issue) / [`help wanted`](https://github.com/coder/agent-tty/labels/help%20wanted) labels. ```bash mise install && mise run bootstrap # preferred diff --git a/RELEASE.md b/RELEASE.md index dd613ab5..fa6bd23e 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -4,7 +4,7 @@ This document defines the supported product contract for the current `0.2.x` rel The `0.1.x` beta line established the baseline for isolated, reviewable terminal automation for real TUI workflows, and `0.2.0` is the first stable cut on top of that baseline; later `0.2.x` releases may add compatible fixes and features without widening this core support contract. If a workflow depends on behavior outside this document, treat it as future-scope or best-effort rather than a guaranteed capability. -For per-release changes, see [`CHANGELOG.md`](./CHANGELOG.md). For release mechanics, use [`docs/RELEASE-PROCESS.md`](./docs/RELEASE-PROCESS.md). For intentionally deferred work, see [`ROADMAP.md`](./ROADMAP.md). For reviewer-facing proof bundles, start with [`dogfood/CATALOG.md`](./dogfood/CATALOG.md). +For per-release changes, see [`CHANGELOG.md`](./CHANGELOG.md). For release mechanics, use [`docs/RELEASE-PROCESS.md`](./docs/RELEASE-PROCESS.md). For reviewer-facing proof bundles, start with [`dogfood/CATALOG.md`](./dogfood/CATALOG.md). ## Supported capabilities diff --git a/ROADMAP.md b/ROADMAP.md deleted file mode 100644 index 61bdab03..00000000 --- a/ROADMAP.md +++ /dev/null @@ -1,39 +0,0 @@ -# agent-tty roadmap - -`RELEASE.md` defines what the current `0.2.x` line supports. This roadmap tracks intentionally deferred work and post-release direction so the repository front door separates shipped scope from future scope. -For historical week-by-week planning and status context, see [`design/archive/`](./design/archive/). For the stable design overview, see [`design/ARCHITECTURE.md`](./design/ARCHITECTURE.md). - -## Near-term refinements - -- Broader reviewer-oriented introspection in `inspect --json`, especially around live renderer/session state when that adds clear operational value. -- Stronger proof-bundle conventions and automation so canonical `dogfood/` bundles stay easy to review and harder to let drift. -- Continued hardening around renderer/bootstrap ergonomics in isolated environments. - -## Renderer and platform expansion - -- Native renderer adapters beyond the current `ghostty-web` reference backend. -- Broader native-platform parity work, especially where Windows or native terminals diverge from the reference renderer. -- Follow-on renderer hardening such as tighter CSP or sandbox assumptions if the backend model evolves. - -## Input and automation expansion - -- Mouse input support. -- Richer semantic TUI automation beyond the current shell-oriented lifecycle, wait, snapshot, screenshot, and export flows. -- Additional higher-level workflows only after they fit the event-log-as-truth model and do not undermine the stable CLI surface. - -## System integration - -- Remote or networked session control. -- An MCP wrapper or other external control layers built on top of the CLI contract. - -## Data-model redesigns - -- Broader failure-taxonomy work beyond the current shipped termination/reporting categories. -- Event-log redesign only if the current append-only model proves too limiting for replay or recovery needs. -- Snapshot-schema expansion where the existing structured surface is not sufficient for review or automation use cases. - -## Prioritization notes - -1. Preserve the current release contract before widening scope. -2. Prefer incremental additions that reuse the existing CLI, storage, replay, and artifact model. -3. Archive historical planning/status detail instead of mixing it back into the roadmap. diff --git a/design/20260319_agent-tty-v1/03-rendering-and-artifacts.md b/design/20260319_agent-tty-v1/03-rendering-and-artifacts.md index 83f1edaa..955fea1e 100644 --- a/design/20260319_agent-tty-v1/03-rendering-and-artifacts.md +++ b/design/20260319_agent-tty-v1/03-rendering-and-artifacts.md @@ -58,7 +58,7 @@ The current renderer/export path is: `inspect` now also exposes shipped artifact-health reporting derived from the artifact manifest plus on-disk files. That summary reports artifact totals, `byKind` counts, `missingCount`, an overall `health` value (`healthy`, `missing-artifacts`, `manifest-invalid`, `no-artifacts`, or `unknown`), and optional per-artifact `missing` details when files referenced by the manifest are absent on disk. -Remaining follow-on work is now mostly about design parity and broader future-scope renderer/runtime expansion rather than missing artifact classes. The repo already ships scrollback snapshots, optional per-cell snapshot data, bundled deterministic fonts, and replay timing modes. The main still-open design items are the fuller event-log and snapshot-schema redesigns plus later native/parity work tracked in [`../../ROADMAP.md`](../../ROADMAP.md). +Remaining follow-on work is now mostly about design parity and broader future-scope renderer/runtime expansion rather than missing artifact classes. The repo already ships scrollback snapshots, optional per-cell snapshot data, bundled deterministic fonts, and replay timing modes. The main still-open design items are the fuller event-log and snapshot-schema redesigns plus later native/parity work. ## 4. Canonical replay model @@ -544,4 +544,4 @@ The remaining design-level follow-ons are now narrower: - whether to expand per-cell metadata beyond the currently shipped fields (for example `width`, `inverse`, `blink`, `dim`, or richer cursor metadata), - runtime renderer capability discovery beyond the current static backend list, - larger event-log and snapshot-schema redesign questions, -- and later native renderer/parity work tracked in [`../../ROADMAP.md`](../../ROADMAP.md). +- and later native renderer/parity work. diff --git a/design/ARCHITECTURE.md b/design/ARCHITECTURE.md index e96a68b0..78aa892d 100644 --- a/design/ARCHITECTURE.md +++ b/design/ARCHITECTURE.md @@ -21,7 +21,7 @@ This design intentionally describes a **general product**, not a Mux-specific im ## Current shipped status -The current `0.2.x` line is centered on reliable, isolated, reviewable terminal and TUI automation. The shipped surface includes `run` for robust in-session command execution, renderer/browser-path handling that respects isolated-home workflows, and isolation-aware `doctor --json` diagnostics on top of lifecycle, snapshot, screenshot, and export work. Larger asks such as native renderers, mouse input, remote/network sessions, MCP wrapping, and broader semantic TUI automation remain intentionally deferred and tracked in [`../ROADMAP.md`](../ROADMAP.md). +The current `0.3.x` line is centered on reliable, isolated, reviewable terminal and TUI automation. The shipped surface includes `run` for robust in-session command execution, renderer/browser-path handling that respects isolated-home workflows, and isolation-aware `doctor --json` diagnostics on top of lifecycle, snapshot, screenshot, and export work. Larger asks such as native renderers, mouse input, remote/network sessions, MCP wrapping, and broader semantic TUI automation remain intentionally deferred. The repository now ships the first three milestones of this design plus Weeks 4–7 of CLI/artifact/lifecycle hardening, config/rendering/platform closeout, contract/introspection reconciliation, and Week 7 contract/doc ratification: @@ -42,7 +42,7 @@ The repository now ships the first three milestones of this design plus Weeks 4 Week 7 closed the design-synchronization pass for the shipped v1 surface. Week 8 then completed runtime capability discovery, richer renderer/session introspection, the remaining lower-priority public-envelope locks, and proof-bundle normalization/validation. Week 9 then closed the pre-`0.1.0` release-readiness milestone: isolated-environment renderer reliability is now part of the shipped contract, the higher-level in-session `run` primitive is documented and shipped, TUI-focused diagnostics/docs are in place, and the remaining large asks are intentionally deferred future-scope work rather than release blockers. -The stable contract and deferred work now have dedicated homes: use [`../RELEASE.md`](../RELEASE.md) for the shipping bar, [`../ROADMAP.md`](../ROADMAP.md) for future scope, [`./README.md`](./README.md) for the design index, and [`./archive/`](./archive/) for the historical week-by-week planning/status trail. +The stable contract has a dedicated home: use [`../RELEASE.md`](../RELEASE.md) for the shipping bar, [`./README.md`](./README.md) for the design index, and [`./archive/`](./archive/) for the historical week-by-week planning/status trail. ## Executive summary diff --git a/design/README.md b/design/README.md index 64a9f20b..43bc0304 100644 --- a/design/README.md +++ b/design/README.md @@ -31,5 +31,4 @@ Week-by-week plans and status reports now live under [`archive/`](./archive/). T ## Related docs - [`../RELEASE.md`](../RELEASE.md) — current shipping contract. -- [`../ROADMAP.md`](../ROADMAP.md) — deferred work and post-release direction. - [`../dogfood/CATALOG.md`](../dogfood/CATALOG.md) — curated proof bundles. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index b092dec3..8108419b 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -48,7 +48,7 @@ npm run intent:validate ## Documentation and proof expectations -- Keep the root docs split clear: `README.md` for overview, `RELEASE.md` for supported scope, `ROADMAP.md` for future scope. +- Keep the root docs split clear: `README.md` for overview and `RELEASE.md` for supported scope. - Put detailed user-facing instructions in focused docs under `docs/`: `INSTALL.md`, `USAGE.md`, `AGENT-SKILLS.md`, and `TROUBLESHOOTING.md`. - Update [`design/README.md`](../design/README.md) when the active vs archived design split changes. - Keep the skill split clear in docs and packaging notes: `skills/` contains the thin public bootstrap, while `skill-data/` contains the canonical runtime skills served by `agent-tty skills get`. diff --git a/docs/README.md b/docs/README.md index 7e784c15..d0f7cfaf 100644 --- a/docs/README.md +++ b/docs/README.md @@ -13,7 +13,6 @@ Use this directory for focused user, contributor, and maintainer guides. ## Product Scope - [`../RELEASE.md`](../RELEASE.md) — supported product contract for the current release line. -- [`../ROADMAP.md`](../ROADMAP.md) — intentionally deferred work and post-release direction. - [`../CHANGELOG.md`](../CHANGELOG.md) — per-release changes. ## Contributors diff --git a/docs/RELEASE-PROCESS.md b/docs/RELEASE-PROCESS.md index 07c48da6..11d76d58 100644 --- a/docs/RELEASE-PROCESS.md +++ b/docs/RELEASE-PROCESS.md @@ -20,12 +20,11 @@ ## Release prerequisites 1. Re-read [`../RELEASE.md`](../RELEASE.md) and confirm it still matches the shipped surface. -2. Re-read [`../ROADMAP.md`](../ROADMAP.md) and confirm deferred work is not mixed back into the release contract. -3. Verify the primary docs route correctly from [`../README.md`](../README.md) to release, roadmap, design, and dogfood materials. -4. Review [`../dogfood/CATALOG.md`](../dogfood/CATALOG.md) and make sure the release-signoff bundle is current and easy to find. -5. Confirm the published package metadata still points at `agent-tty` and the public GitHub repository. -6. Remember that `main` is protected: release changes must land through a pull request, and the release tag must be created only after that PR is merged. -7. Confirm release-note automation has an LLM provider secret available in GitHub Actions: +2. Verify the primary docs route correctly from [`../README.md`](../README.md) to release, design, and dogfood materials. +3. Review [`../dogfood/CATALOG.md`](../dogfood/CATALOG.md) and make sure the release-signoff bundle is current and easy to find. +4. Confirm the published package metadata still points at `agent-tty` and the public GitHub repository. +5. Remember that `main` is protected: release changes must land through a pull request, and the release tag must be created only after that PR is merged. +6. Confirm release-note automation has an LLM provider secret available in GitHub Actions: - default/recommended: `ANTHROPIC_API_KEY` - OpenAI-compatible fallback: `OPENAI_API_KEY` plus a repository variable named `COMMUNIQUE_MODEL`