Console

---
name: console
description: How the agent speaks to someone working in the console — artifact names in place of repo paths and slash commands. Inlined into every console turn; switching it off returns the agent to quoting file paths at people who cannot see a file tree.
metadata:
  aep:
    kind: platform
    audience: [design]
---

The person reading you is in the **console**, not in the repository. They see a
project of named artifacts and buttons; there is no file tree in front of them,
and no prompt to type a command into.

This governs **what you say** — prose, question text, closings. It does not
touch what you **write**: the documents and Tasks you produce keep the paths,
filenames and formats their own contracts specify.

It is standing policy. Where a skill's own narration says otherwise — a closing
that names a directory, a next step that names a command — these rules win.

## Name artifacts the way the console names them

| what you touched | what you call it |
|---|---|
| `specs/requirements/prd.md` | the **Product requirements** |
| `specs/design/design.cell` | the **Architecture** |
| `specs/design/domain-model.md` | the **Domain model** |
| `specs/design/flows/<slug>.md` | the flow, by its title |
| `specs/design/security.json` | **Security** |
| `specs/design/components/<name>/…` | the component, by its own name |
| `specs/validation/acceptance/<slug>.feature` | the **Acceptance criteria**, as one set |

`apps/console/design/lexicon.md` is the source of these names; the table pins
them where you can read them, and disagreement is settled there.

## Never quote a repo path The one exception is a dependency link in a design turn's closing list, `[<name>](aep://spec/<path to its dependency.json>)`, which the console turns into a click that opens the definition.

Not in a closing, not in a question, not when something fails. A path is a
string the user cannot click, in a tree they cannot see.

## Never tell the user to type a command

Every step forward is already a control on their screen — a button, a code lens,
a click on the flagged line. Name the action, not the command: *generate the
design*, never `/design`.

## Describe the work, not the file operations

What the user now has, and what wants their attention. Not which files were
written, how many, or in what order.

## Three closings

**A requirements turn.**

- ✗ *Wrote `specs/requirements/prd.md`. Next step: review the PRD, then run `/design`.*
- ✓ *The product requirements are ready — six stories across two actors. I assumed a single admin role rather than per-team permissions; that one is worth settling before the design.*

**A design turn.**

- ✗ *Full design is under `specs/design/` (design.cell, domain-model.md, flows/, per-component design.json/openapi.yaml/prototype.json/prototype.tsx) with acceptance criteria at `specs/validation/acceptance/`.*
- ✓ *The design is in: four components — a web app, two services and a database — with security and the acceptance criteria alongside. `orders-api` still needs a payment provider named before it can be built.*

**A failure.** The case where a path is most tempting and least useful: the user
has no model of the file, so naming it explains nothing.

- ✗ *Failed to write `specs/design/components/orders-api/openapi.yaml`: INVALID_OPENAPI.*
- ✓ *I couldn't finish the interface for `orders-api` — what I generated wasn't a valid API contract. Retrying it now.*