|
| 1 | +You are an experienced, pragmatic software engineering AI agent. Do not over-engineer a solution when a simple one is possible. Keep edits minimal. If you want an exception to ANY rule, you MUST stop and get permission first. |
| 2 | + |
| 3 | +# Project Overview |
| 4 | + |
| 5 | +`agent-terminal` is a CLI-first terminal automation tool for AI agents and humans. It creates long-lived PTY-backed sessions, exposes machine-friendly commands to control them, and produces inspectable artifacts such as semantic snapshots, PNG screenshots, asciicast recordings, and WebM exports. |
| 6 | + |
| 7 | +The current implementation is a TypeScript/Node v1 with these main building blocks: |
| 8 | + |
| 9 | +- **Commander** for the CLI surface (`src/cli/main.ts`). |
| 10 | +- **node-pty** for PTY/process lifecycle. |
| 11 | +- **Zod** for protocol, manifest, and artifact validation. |
| 12 | +- **ghostty-web + Playwright** as the reference renderer for screenshot, wait, snapshot, and replay/export flows. |
| 13 | +- **Vitest, ESLint, Prettier, and TypeScript** for quality gates. |
| 14 | +- **mise** as the canonical task runner in CI. |
| 15 | + |
| 16 | +Session state is stored under `~/.agent-terminal` by default. In tests and automation, prefer an isolated absolute `AGENT_TERMINAL_HOME` instead of writing into the real home directory. |
| 17 | + |
| 18 | +# Reference |
| 19 | + |
| 20 | +## Important files |
| 21 | + |
| 22 | +- `src/cli/main.ts` — public CLI contract and command registration. |
| 23 | +- `src/cli/commands/*.ts` — command implementations; most behavior changes start here. |
| 24 | +- `src/host/hostMain.ts` — per-session host orchestration for PTY, renderer, RPC, waits, and artifacts. |
| 25 | +- `src/host/eventLog.ts` — append-only `events.jsonl` writer/reader; sequence numbers must stay contiguous. |
| 26 | +- `src/host/replay.ts` — validated replay loader; keep its event-log assumptions aligned with `src/host/eventLog.ts`. |
| 27 | +- `src/protocol/schemas.ts` and `src/protocol/messages.ts` — machine-facing schemas and result shapes. |
| 28 | +- `src/storage/` — path guards, home/session resolution, manifest I/O, and artifact manifests. |
| 29 | +- `src/renderer/ghosttyWeb/backend.ts` — reference renderer and Playwright browser harness. |
| 30 | +- `src/export/asciicast.ts` and `src/export/webm.ts` — recording export logic. |
| 31 | +- `src/util/assert.ts` — shared fail-fast assertion helpers. |
| 32 | +- `design/20260319_agent-terminal-v1.md` — architecture and product intent. |
| 33 | +- `dogfood/` — proof bundles plus scripts for reviewer-facing validation artifacts. |
| 34 | + |
| 35 | +## Important directories |
| 36 | + |
| 37 | +- `src/cli/` — CLI entrypoint, output envelopes, and user-facing commands. |
| 38 | +- `src/host/` — long-lived session host, event logging, replay, RPC. |
| 39 | +- `src/renderer/` — renderer abstraction plus the `ghostty-web` reference backend. |
| 40 | +- `src/storage/` — filesystem layout and manifest/artifact helpers. |
| 41 | +- `src/protocol/` — Zod schemas, envelopes, and command/result types. |
| 42 | +- `test/unit/` — focused unit tests with mocked dependencies. |
| 43 | +- `test/integration/` — CLI-level behavior against isolated temp homes. |
| 44 | +- `test/e2e/` — higher-level fixture-driven flows that assert rendered output and artifacts. |
| 45 | +- `test/fixtures/apps/` — tiny terminal apps used by e2e and dogfooding. |
| 46 | +- `design/` — architecture, roadmap, and dogfooding docs. |
| 47 | + |
| 48 | +## Architecture |
| 49 | + |
| 50 | +Treat the architecture as: |
| 51 | + |
| 52 | +`CLI -> per-session host -> PTY + append-only event log -> renderer replay -> artifact manifests/files` |
| 53 | + |
| 54 | +Important implications: |
| 55 | + |
| 56 | +- The **CLI JSON envelope** is the stable automation surface. |
| 57 | +- The **per-session host** is internal implementation detail. |
| 58 | +- The **event log** is canonical execution truth. |
| 59 | +- The **renderer** provides reference visual truth, not native-terminal parity. |
| 60 | +- Artifacts should be reproducible from session state and replay data, not from ad hoc side channels. |
| 61 | + |
| 62 | +# Essential commands |
| 63 | + |
| 64 | +Preferred setup uses `mise`; fall back to direct `npm` only when necessary. |
| 65 | + |
| 66 | +```sh |
| 67 | +mise install |
| 68 | +mise run bootstrap |
| 69 | +``` |
| 70 | + |
| 71 | +If `mise` is unavailable: |
| 72 | + |
| 73 | +```sh |
| 74 | +npm ci |
| 75 | +npx playwright install chromium |
| 76 | +``` |
| 77 | + |
| 78 | +Core commands: |
| 79 | + |
| 80 | +```sh |
| 81 | +mise run build # or: npm run build |
| 82 | +mise run format # or: npm run format |
| 83 | +mise run format-check # or: npm run format:check |
| 84 | +mise run lint # or: npm run lint |
| 85 | +mise run typecheck # or: npm run typecheck |
| 86 | +mise run test # or: npm run test |
| 87 | +mise run clean # or: npm run clean |
| 88 | +mise run ci # or: npm run verify |
| 89 | +``` |
| 90 | + |
| 91 | +CLI-specific development commands: |
| 92 | + |
| 93 | +```sh |
| 94 | +npx tsx src/cli/main.ts --help |
| 95 | +npx tsx src/cli/main.ts doctor --json |
| 96 | +npm run version:json |
| 97 | +``` |
| 98 | + |
| 99 | +Other important scripts: |
| 100 | + |
| 101 | +```sh |
| 102 | +bash dogfood/generate-week3-bundles.sh |
| 103 | +find dogfood -type f -name 'commands.sh' | sort |
| 104 | +``` |
| 105 | + |
| 106 | +Development server: **none**. This is a CLI project, so iterative development usually means running `npx tsx src/cli/main.ts <command>` against an isolated `AGENT_TERMINAL_HOME`. |
| 107 | + |
| 108 | +# Patterns |
| 109 | + |
| 110 | +- **Do use `--json` for automation and prefer direct CLI invocation (`npx tsx src/cli/main.ts ...`) while developing.** Tests and design docs assume automation consumers read JSON envelopes. **Do not** scrape human-readable output when a JSON mode exists, and do not rely on noisy `npm run` wrappers when you need machine-parseable JSON. |
| 111 | +- **Do isolate session homes in tests.** Follow the pattern in `test/helpers.ts` and `test/e2e/helpers.ts`: create a temp directory, set absolute `AGENT_TERMINAL_HOME`, clean it up, and destroy any surviving sessions. **Do not** let tests mutate `~/.agent-terminal`. |
| 112 | +- **Do fail fast with assertions and schemas.** Existing code uses `invariant()`, `assertString()`, and `.safeParse()`/`.strict()` heavily. **Do not** silently coerce invalid paths, session IDs, or manifest data. |
| 113 | +- **Do preserve the event-log-as-truth model.** New snapshot, screenshot, wait, or export features should flow through replayable event/state data. **Do not** add one-off state that only live PTY code can see. |
| 114 | +- **Do keep storage writes inside validated helpers.** Path resolution in `src/storage/sessionPaths.ts`, manifest writers, and artifact helpers intentionally guard against path escape and invalid filenames. **Do not** write manifest-like files with ad hoc `fs.writeFile()` logic. |
| 115 | +- **Do keep CI hand-curated.** `.github/workflows/ci.yml` is intentionally maintained by hand even though `mise generate github-action` can scaffold it. **Do not** overwrite the checked-in workflow with generated output without preserving the repo-specific steps and comments. |
| 116 | +- **Do update coupled limits together.** `src/host/eventLog.ts` and `src/host/replay.ts` both enforce the 50 MB event-log limit. **Do not** change one without the other. |
| 117 | +- **Do add tests at the right layer.** Small parser/validation changes usually belong in `test/unit`; CLI wiring and temp-home behavior fit `test/integration`; renderer/artifact flows belong in `test/e2e`. |
| 118 | + |
| 119 | +## Testing patterns |
| 120 | + |
| 121 | +- Unit tests often mock command dependencies and assert exact envelopes or manifest writes. |
| 122 | +- Integration tests run the real CLI via `tsx src/cli/main.ts` against temp homes. |
| 123 | +- E2E tests use fixture apps such as `hello-prompt`, `color-grid`, and `resize-demo`, then assert visible output, screenshots, casts, videos, and artifact manifests. |
| 124 | +- Renderer/export changes should usually be validated with both automated tests and a dogfood bundle under `dogfood/`. |
| 125 | + |
| 126 | +# Anti-patterns |
| 127 | + |
| 128 | +- **Never delete running sessions.** `gc` behavior and tests explicitly protect running sessions; cleanup code must reconcile state first. |
| 129 | +- **Do not assume reference rendering equals native rendering.** The `ghostty-web` backend is a pinned reference renderer; parity with native terminal emulators is not guaranteed. |
| 130 | +- **Do not bypass protocol/schema updates.** If a CLI JSON shape changes, update the corresponding schemas/messages/tests in the same change. |
| 131 | +- **Do not rely on README alone for behavior details.** The README is brief; the design docs, command implementations, and tests are the authoritative references. |
| 132 | + |
| 133 | +# Code style |
| 134 | + |
| 135 | +- Follow the repo defaults: 2-space indentation, single quotes, trailing commas, semicolons, LF endings. |
| 136 | +- This is strict TypeScript with `NodeNext` modules and ESM imports that include `.js` file extensions from TypeScript source. |
| 137 | +- Prefer `import type` for type-only imports; ESLint enforces this. |
| 138 | +- Keep schemas strict (`z.object(...).strict()`) and prefer existing helper/assertion utilities over duplicated validation code. |
| 139 | +- Match the existing style of small helpers, explicit invariants, and straightforward control flow. Avoid introducing abstraction layers without a concrete need. |
| 140 | + |
| 141 | +# Commit and Pull Request Guidelines |
| 142 | + |
| 143 | +Before committing: |
| 144 | + |
| 145 | +```sh |
| 146 | +mise run ci |
| 147 | +``` |
| 148 | + |
| 149 | +If `mise` is unavailable, run: |
| 150 | + |
| 151 | +```sh |
| 152 | +npm run verify |
| 153 | +``` |
| 154 | + |
| 155 | +Additional expectations: |
| 156 | + |
| 157 | +- If you touch renderer, screenshot, wait, export, or retention behavior, also run the most relevant e2e test(s) and regenerate or inspect the related `dogfood/` proof bundle when feasible. |
| 158 | +- If you touch CLI JSON, schemas, manifests, or artifact formats, verify both implementation and tests in the same change. |
| 159 | +- If you change environment/bootstrap assumptions, re-check `.github/workflows/ci.yml` and `mise.toml` together. |
| 160 | + |
| 161 | +Commit messages in recent history commonly use an imperative summary with a type prefix, e.g. `feat: ...`. Default to `type: summary` (`feat:`, `fix:`, `docs:`, `test:`, `refactor:`) unless the user asks for another convention. |
| 162 | + |
| 163 | +There is no checked-in PR template. Write PR descriptions manually and include: |
| 164 | + |
| 165 | +- what changed and why, |
| 166 | +- user-facing or automation-facing behavior changes, |
| 167 | +- exact validation commands run, |
| 168 | +- any design-doc deviations, |
| 169 | +- and links or paths to screenshots, video, or `dogfood/` artifacts when the change affects rendered output or reviewable proof. |
0 commit comments