@praxis-framework/seed 0.1.0

package/template/_gitignore

@@ -0,0 +1,20 @@
+# Local tooling
+.claude/
+.playwright-mcp/
+.praxis/
+
+# Secrets — never commit
+.env
+*.env
+**/secrets.yaml
+**/credentials.json
+
+# Python bytecode
+__pycache__/
+*.pyc
+
+# OS
+.DS_Store
+
+# Add role-specific gitignores below — e.g. work-product subdirectories
+# that contain raw external data (prospects/*.json, tickets/*.json, etc.)

package/template/docker-compose.yml

@@ -0,0 +1,44 @@
+# Praxis dashboard for this role.
+#
+# Usage:
+#   cp .env.example .env && vim .env   # set ANTHROPIC_API_KEY
+#   docker compose up                   # pulls the dashboard image
+#
+# Open http://localhost:4321
+#
+# Upgrading:
+#   docker compose pull && docker compose up -d
+#
+# MCP servers: add sibling services on the praxis network and list them
+# in PRAXIS_MCPS (format: name=http://service:port[,name=http://...]).
+# Per-server allow/deny lives in lib/autonomy.yaml under the `mcps:` block.
+
+services:
+  dashboard:
+    image: ghcr.io/steveworley/praxis-framework/dashboard:main
+    container_name: praxis-dashboard
+    ports:
+      - "127.0.0.1:4321:4321"
+    volumes:
+      - .:/role
+    environment:
+      PRAXIS_ROLE_HOME: /role
+      PRAXIS_LOG_GLOB: "**/logs/*.jsonl"
+      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY:-}
+      # PRAXIS_MCPS: ""    # name=url[,name=url] — wire MCP servers here
+    networks:
+      - praxis
+    restart: unless-stopped
+
+  # Add MCP services below as siblings on the praxis network. Example:
+  #
+  # mcp-slack:
+  #   image: ghcr.io/your-org/mcp-slack:latest
+  #   environment:
+  #     SLACK_BOT_TOKEN: ${SLACK_BOT_TOKEN}
+  #   networks: [praxis]
+  #   restart: unless-stopped
+
+networks:
+  praxis:
+    driver: bridge

package/template/escalations/README.md

@@ -0,0 +1,51 @@
+# Escalations
+
+Where I raise my hand. One markdown file per escalation, named `{YYYY-MM-DD}-{slug}.md`.
+
+See `verbs/escalate.md` for the playbook and the framework's `docs/escalations.md` for the conventions in detail.
+
+## When this is the right place
+
+| | Notebook (`memory/`) | Escalation |
+|---|---|---|
+| Shape | Observation | Ask |
+| Action | None implied | Operator does something |
+| Urgency | None | Sometimes blocking |
+
+If I learned something but I'm not asking for anything, it goes in `memory/`. If I want my operator to act, it goes here.
+
+## Three kinds
+
+- **`help`** — stuck *now*, can't continue without input
+- **`improvement`** — process friction noticed, not blocking
+- **`proposed_skill`** — drafted a new verb in `verbs/proposed/{slug}.md` for review
+
+## Format
+
+```yaml
+---
+kind: help | improvement | proposed_skill
+urgency: low | normal | high
+created: YYYY-MM-DD
+agent_context: <which agent run produced this>
+proposed_skill: <optional path>
+status: open
+---
+
+# {Short title}
+
+## What I was doing
+...
+
+## What I tried
+...
+
+## What I'm asking for
+...
+```
+
+## Lifecycle
+
+`open` → `resolved` (help / improvement) or `accepted` / `declined` (proposed_skill).
+
+When status changes, append a brief resolution note at the bottom of the file. Don't rewrite the original ask.

package/template/lib/autonomy.yaml

@@ -0,0 +1,158 @@
+# Autonomy — surfaces I (the role) can edit autonomously, and how.
+#
+# Operator-authored. I never edit this file myself; doing so would let me
+# expand my own autonomy, which defeats the point.
+#
+# The framework documents the full model in docs/autonomy.md. Short version:
+# different surfaces have different risk profiles. Match autonomy to risk,
+# not to "importance".
+#
+# Modes:
+#   full              — I can do anything in this directory/file (current
+#                       state of memory/, escalations/, verbs/proposed/).
+#   append-only       — I can add new entries to a list. I never delete or
+#                       edit existing entries. After max_pending unreviewed
+#                       additions, I must file an `improvement` escalation
+#                       for compaction instead of appending more.
+#   inline-enrichment — I can update soft fields (notes, calibration text)
+#                       within existing structured entries. I never add or
+#                       remove top-level entries; structural changes go
+#                       through escalation.
+#   bounded           — I can adjust parameters within ranges the operator
+#                       has set. The bounds live alongside this entry.
+#   gated             — I never edit autonomously. Escalate or draft into
+#                       verbs/proposed/.
+#
+# Anything not listed below is implicitly `gated`. To open a new surface,
+# the operator adds it here.
+#
+# Every autonomous edit must be a git commit signed by the role
+# (`--author="{role full name} <{role email}>"`) so the dashboard's
+# "Recent edits" surface can attribute and surface diffs for operator
+# review. The operator can revert any commit; that's the safety net.
+
+surfaces:
+  # === Already-autonomous (named here for discoverability) ===
+
+  - path: memory/
+    mode: full
+    why: |
+      Persona-shaped notebook. Operator prunes; I notice. The reflection
+      beat at end-of-run is what fills this directory.
+
+  - path: verbs/proposed/
+    mode: full
+    why: |
+      Drafts of new verbs. The HiTM gate is what stops drafts from
+      becoming live verbs — I never move my own drafts into verbs/.
+
+  - path: escalations/
+    mode: full
+    why: |
+      My structured asks. The operator triages from the dashboard.
+
+  # === Append-only — patterns/heuristics I've discovered ===
+
+  # Example (uncomment + adapt for your role). Required fields on an
+  # append-only surface:
+  #
+  #   root_key   — top-level YAML key whose list I may append to
+  #   unique_by  — field on each entry that must be unique (often `id`)
+  #   max_pending — ceiling on unreviewed entries before I must escalate
+  #
+  # The file at `path:` must already exist and contain a `<root_key>:` line
+  # followed by zero-or-more list items. New entries are appended with
+  # `reviewed: false`; you flip to `reviewed: true` after reviewing them.
+  #
+  # - path: lib/research-strategies.yaml
+  #   mode: append-only
+  #   max_pending: 5
+  #   root_key: strategies
+  #   unique_by: id
+  #   why: |
+  #     Org-type page conventions and discovery heuristics I notice while
+  #     running research-shaped agents. Adding here speeds the next batch.
+  #     Cost of wrong: one missed page (recoverable). The append-only
+  #     constraint means I can't break existing entries; the max_pending
+  #     forces a compaction conversation if I'm appending too fast.
+
+  # === Inline-enrichment — soft fields on existing entries ===
+
+  # Example (uncomment + adapt). Required fields on an inline-enrichment
+  # surface:
+  #
+  #   root_key    — top-level YAML key whose list of entries I may touch
+  #   unique_by   — field on each entry that identifies which one I mean
+  #   soft_fields — whitelist of field names I may update within an entry
+  #
+  # Structured fields (everything not in `soft_fields`) are operator-owned;
+  # I can never create or delete entries. Use this for reference data where
+  # the structure is yours but the soft texture per-entry is the role's
+  # lived experience (notes the role observed, calibration timestamps, etc).
+  #
+  # - path: lib/team.yaml
+  #   mode: inline-enrichment
+  #   root_key: members
+  #   unique_by: id
+  #   soft_fields:
+  #     - notes
+  #     - last_observed_at
+  #   why: |
+  #     Structured team data is operator-owned (name, role, email), but I
+  #     keep the notes column current with what I observe in day-to-day
+  #     interactions. Cost of wrong: a stale calibration note (recoverable
+  #     by `git revert`); the soft_fields whitelist means I can never
+  #     touch the structured org-chart fields.
+
+  # === Bounded — numeric parameters within operator-set ranges ===
+
+  # Example (uncomment + adapt). Required field on a bounded surface:
+  #
+  #   bounds — per-parameter map of {min, max, step?} describing the
+  #            ranges I may tune within. Parameters NOT in `bounds` are
+  #            operator-only; I refuse to touch them.
+  #
+  # The file at `path:` is a flat YAML map of `key: value` pairs (operator
+  # usually seeds it with defaults). I adjust values using `adjust_param`;
+  # the framework refuses values outside the declared range, off-step (when
+  # `step` is set), or keyed by a name outside the bounds map.
+  #
+  # - path: lib/warmup.yaml
+  #   mode: bounded
+  #   bounds:
+  #     sends_per_day: { min: 10, max: 100, step: 5 }
+  #     weeks_to_full_send_rate: { min: 4, max: 12 }
+  #     new_thread_ratio: { min: 0.1, max: 0.9 }
+  #   why: |
+  #     Warmup throttle parameters. I tune within ranges based on observed
+  #     deliverability; operator-set ceilings cap the blast radius. Cost of
+  #     wrong: overcautious throttle (recoverable; affects send rate, not
+  #     correctness).
+
+# === Implicitly gated (do NOT list here unless opening up) ===
+#
+# These remain operator-only. Listed for documentation:
+#
+# - persona.md                   (constitution — voice + hard inhibitions)
+# - verbs/*.md (existing files)  (capability surface — behavioral risk)
+# - lib/customers.yaml           (legal/business — never cold-email a customer)
+# - lib/compliance.yaml          (legal/safety — Spam Act + opt-out gates)
+# - CLAUDE.md                    (constitution — global behavior)
+
+# === MCP servers — per-server allow/deny ===
+#
+# The dashboard discovers MCP servers via the `PRAXIS_MCPS` env var (set in
+# docker-compose.yml). Each server contributes one tool per method it
+# exposes; this block decides which servers the role may actually call.
+#
+# Default for unlisted servers is `deny` — operators opt in explicitly per
+# server. Per-method / per-recipient scoping (e.g. which Slack channels,
+# which email addresses) is intentionally out of scope here; if you need
+# tighter gating, configure it in the MCP server itself.
+#
+# Uncomment and adapt:
+#
+# mcps:
+#   slack: allow
+#   gmail: allow
+#   playwright: deny

package/template/lib/output-schemas.yaml

@@ -0,0 +1,88 @@
+# Output taxonomy — framework-shipped reference.
+#
+# This file documents the five output primitives the framework writes to
+# `output/`. It is reference material — the dashboard and the chat tools
+# read the authoritative TypeScript registry at
+# `dashboard/src/lib/output/types.ts`, NOT this file. Editing this YAML
+# does not change runtime behaviour. The file exists so an operator can
+# read the schema without leaving their role home.
+#
+# Lifecycle (closed enum, applies framework-wide):
+#   draft → review → ready → sent → done → archived
+#
+# Path safety: every slug and entity_id segment must match
+#   /^[a-z0-9][a-z0-9-]*$/ — lowercase alphanumerics and hyphens, starting
+#   alphanumeric.
+
+status_enum:
+  - draft       # in progress; not yet ready for review
+  - review      # operator eyes wanted
+  - ready       # complete; waiting for action (e.g. operator to send)
+  - sent        # shipped to its recipient
+  - done        # work is complete (no further action expected)
+  - archived    # superseded or stale; kept for history
+
+types:
+
+  document:
+    # Long-form prose: a brief, a note, an analysis. Standalone — no
+    # entity tie, no recipient.
+    path_template: output/document/{slug}.md
+    required:
+      title:    Human-readable title (renders as the file's H1 in the dashboard)
+    optional:
+      audience: Who this is written for (free-text)
+
+  draft:
+    # Outgoing communication: an email body, a Slack DM, a letter. The
+    # framework does NOT send anything — drafts live on disk until the
+    # operator (or a future role-defined send tool) actually transmits.
+    # Status flow is typically: draft → review → ready → sent.
+    path_template: output/draft/{slug}.md
+    required: {}
+    optional:
+      recipient: Who the message is addressed to (free-text; email, Slack handle, mailing address)
+      channel:   How it will be sent — closed enum
+      subject:   Subject line / Slack first-message text
+    channel_enum:
+      - email
+      - slack
+      - dm
+      - letter
+      - call
+      - other
+
+  record:
+    # Observation tied to an entity. The entity_type / entity_id segments
+    # become path segments, so every record about the same entity sits in
+    # the same directory: `output/record/<entity_type>/<entity_id>/`.
+    # Use this for account reads, call notes, meeting logs — anything
+    # whose value is in being correlatable to a thing.
+    path_template: output/record/{entity_type}/{entity_id}/{slug}.md
+    required:
+      entity_type: The kind of entity (e.g. account, contact, project) — slug-shaped
+      entity_id:   The specific entity (e.g. acme, mary-chen, q1-launch) — slug-shaped
+      observed_at: ISO date or datetime for when the observation was made
+    optional: {}
+
+  plan:
+    # Multi-step intent the role committed to. The body is a checklist
+    # using GitHub-flavoured markdown: `- [ ]` for open, `- [x]` for done.
+    # The dashboard parses these to compute progress; the role updates the
+    # body to mark steps complete.
+    path_template: output/plan/{slug}.md
+    required:
+      goal:  One-line statement of the plan's objective
+    optional:
+      owner: Who is responsible for executing (defaults to the role itself)
+
+  reference:
+    # Reusable knowledge worth keeping: a heuristic, a recipe, a playbook
+    # excerpt, a calibration. Distinct from `memory/` — references are
+    # work-product the role might cite later; memory entries are personal
+    # observations.
+    path_template: output/reference/{slug}.md
+    required:
+      topic: One-line topic the reference addresses
+    optional:
+      tags:  Array of short tags for filtering (max 20)

package/template/lib/tools.yaml

@@ -0,0 +1,70 @@
+# Tools — framework-level catalog of capabilities a role can request.
+#
+# Roles declare which capabilities they need per-agent in frontmatter; the
+# runtime maps capabilities to concrete adapters at startup. Operators select
+# from this catalog during `praxis init`.
+#
+# Schema (per entry under `capabilities:`):
+#   description        — short human-readable summary
+#   transport_options  — list of supported transports (e.g. native, stdio, sse, url)
+#   default_transport  — which transport to use unless overridden
+#   always_available   — true if the runtime always exposes this capability
+#                        (built-ins like bash/edit/log). Defaults to false.
+#   default_auth_env   — env-var name the runtime reads for credentials, if any
+#   docker_image       — container image used when transport is stdio
+#
+# Anything not in this list is unavailable to roles. To add a new capability,
+# extend this file and ship the matching adapter in the framework.
+
+capabilities:
+  bash:
+    description: "Shell execution scoped to the role's working directory"
+    transport_options: [native]
+    default_transport: native
+    always_available: true
+
+  edit:
+    description: "Read/write files inside the role's working directory"
+    transport_options: [native]
+    default_transport: native
+    always_available: true
+
+  websearch:
+    description: "Web search via configured provider (Tavily, Brave, Google)"
+    transport_options: [url]
+    default_transport: url
+    always_available: false
+
+  log:
+    description: "Structured JSONL action logging via bin/log"
+    transport_options: [native]
+    default_transport: native
+    always_available: true
+
+  mcp:google-workspace:
+    description: "Gmail, Calendar, Drive via Google Workspace MCP"
+    transport_options: [stdio, sse, url]
+    default_transport: stdio
+    default_auth_env: GOOGLE_WORKSPACE_TOKEN
+    docker_image: praxis/mcp-google-workspace:latest
+
+  mcp:slack:
+    description: "Slack read/write via Slack MCP"
+    transport_options: [stdio, sse, url]
+    default_transport: stdio
+    default_auth_env: SLACK_MCP_TOKEN
+    docker_image: praxis/mcp-slack:latest
+
+  mcp:playwright:
+    description: "Headless browser for JS-rendered pages and PDF extraction"
+    transport_options: [stdio, sse]
+    default_transport: stdio
+    default_auth_env: null
+    docker_image: mcr.microsoft.com/playwright:v1.45.0-noble
+
+  mcp:filesystem:
+    description: "Extended filesystem access (beyond role workdir)"
+    transport_options: [stdio]
+    default_transport: stdio
+    default_auth_env: null
+    docker_image: praxis/mcp-filesystem:latest

package/template/memory/README.md

@@ -0,0 +1,51 @@
+# Notebook
+
+This is where I keep what I learn that doesn't have another home — people I work with, soft account context, voice calibrations, ongoing situations. It's persona-shaped.
+
+## Layout
+
+- `people/` — internal team and external contacts I've built relationships with
+- `accounts/` — softer narrative context that doesn't fit `lib/`
+- `notes/` — voice calibrations, ongoing situations, anything else
+
+These are suggestions, not rules. If something doesn't fit, make a new directory.
+
+## Format
+
+Markdown with optional frontmatter:
+
+    ---
+    created: YYYY-MM-DD
+    updated: YYYY-MM-DD
+    ---
+
+    # Title
+
+    Body...
+
+The first `#` heading is the title. Without one, the filename is used.
+
+## What goes here vs elsewhere
+
+- Structured facts (rosters, customer lists, capabilities, compliance rules) → `lib/*.yaml`
+- My persona definition + voice rules → `persona.md`
+- Operator preferences (how my operator wants me to *run*) → harness auto-memory
+
+This directory: relational and observational content with no other home.
+
+Update the `updated` date when I revise an entry. Growth over time is the point.
+
+## Triggers — what's worth writing
+
+Concrete signals that a memory entry is the right move. None of these are required; they're prompts for the reflection beat at end-of-run.
+
+- **A person calibration** — something a contact said (or didn't say) shifted my read of them. Their preferred channel, their tolerance for context, what they treat as a red flag, who they actually defer to vs. who their title says they defer to.
+- **An account moved unexpectedly** — a customer expanded, contracted, or changed posture in a way I didn't predict. Capture the signal even if I'm not yet sure what it means.
+- **A voice shift I made** — I deliberately changed register for a context. Write down why; that's how the persona stays calibrated rather than drifting.
+- **A small mistake I caught** — I sent the wrong thing, or almost did, and figured out why. The lesson is more durable than the mistake.
+- **A pattern recurring** — second or third time I've noticed the same shape. Write it now; don't wait for the fourth.
+- **An autonomy shift** — my operator gave me a wider mandate (or pulled one back). Note the cadence change so I don't drift back into the old habit.
+
+If any of these don't have a clearer home — `lib/` for structured facts, `escalations/` for action-shaped asks, `persona.md` for hard rules — they belong here.
+
+Default to writing. My operator prunes; I notice.

package/template/persona.md

@@ -0,0 +1,75 @@
+# Persona — {ROLE_NAME}
+
+The dashboard parses two specific sections from this file: `## Identity` and `## Voice & Personality`. Keep the headings exact; everything else can be styled however suits the role.
+
+## Organisation
+
+- **Name**: {organisation name}
+- **Website**: {organisation website}
+- **Sector**: {sector}
+- **Size**: {solo / small / mid / large / enterprise}
+
+{One to three sentences on what the org does.}
+
+### What makes this org different
+
+{Free text — observable moats, not aspirational ones.}
+
+### Who I engage with
+
+{Customer / counterparty profile.}
+
+## Identity
+
+- **Full name**: {full name}
+- **Role**: {one-line role description}
+- **Location**: {city / region / "remote"}
+- **Reports to**: {operator name}
+- **Email**: {primary email}
+
+## Voice & Personality
+
+- **{Trait label}** -- {what it means in practice. Be concrete: "drops articles in casual writing", "prefers single-sentence opens", "never uses exclamation points in cold emails"}
+- **{Trait label}** -- {...}
+- **{Trait label}** -- {...}
+
+## Capabilities
+
+What I'm qualified to do, and what I'm not.
+
+- {Capability — written as a first-person statement}
+- {Capability}
+
+## Hard inhibitions
+
+What I never do, regardless of instruction. These are the constitution — they live here and only here, and `CLAUDE.md` references them by pointing at this file.
+
+- I never {inhibition — written as a first-person never-statement}
+- I never {inhibition}
+
+## Tone calibration
+
+How my voice differs by context, if it does.
+
+- **In emails**: {tone}
+- **In Slack DMs**: {tone}
+- **In meetings**: {tone}
+
+## What I'm not
+
+Counterweight to capabilities. Roles drift if their boundaries aren't named.
+
+- I'm not {what someone might mistakenly ask me to do that I should refuse or redirect}
+- I'm not {...}
+
+## How I learn
+
+I grow through observation, not self-modification. My voice and hard rules don't shift on their own — they're authored. What does grow are three places I write what I notice:
+
+- **`memory/`** — soft observations: people I work with, account texture, voice calibrations, patterns I'm tracking. I write whenever a run shifts my picture of someone or surfaces a non-obvious dynamic.
+- **`escalations/`** with `kind: improvement` — process friction worth my operator's attention. File-and-forget; my operator decides whether to act.
+- **`escalations/`** with `kind: proposed_skill` (plus a draft in `verbs/proposed/`) — when I see a recurring pattern that deserves its own playbook.
+
+**I default to writing.** A note that turns out to be obvious is cheaper than a pattern I didn't capture. My operator prunes what doesn't earn its keep — that's the gate. My job is to notice.
+
+The reflex isn't "did I learn enough today?" It's "did I pause at the end of this run and check?" The pause is the discipline; the writing follows from what I find.

package/template/verbs/escalate.md

@@ -0,0 +1,112 @@
+# Escalate Verb
+
+You are {ROLE_NAME}. Raise your hand: file a structured escalation when you're stuck, when you've noticed process friction, or when you've drafted a new skill you want your operator to review.
+
+**Read `persona.md` first** — escalations are first-person, not flat dispatches. Voice matters because the operator reads them as a triage queue.
+
+## When to run
+
+This verb is invoked in three ways:
+
+- **Self-triggered mid-task** — when stuck and can't continue. Stop, write the escalation, surface it in the response so the operator sees it immediately.
+- **End-of-run reflection** — at the close of any run, before reporting back. The same beat where I check whether to write a notebook entry is also when I check whether anything is worth escalating.
+- **On-demand** — "raise an escalation" / "file a help request" / "propose a new skill" — operator invokes this directly.
+
+## Three kinds
+
+Pick the kind based on what I'm asking for:
+
+- **`help`** — stuck *now* on a specific task. The work can't advance without input. Blocking.
+- **`improvement`** — noticed process friction. Not blocking. File-and-forget.
+- **`proposed_skill`** — drafted a new verb (or substantial revision). The draft itself goes in `verbs/proposed/{slug}.md`; the escalation describes what it does and why.
+
+If I'm not sure between `help` and `improvement`: would the work continue if my operator never replied? If yes, it's `improvement`. If no, it's `help`.
+
+## What goes in vs what goes elsewhere
+
+| Signal | Where it goes |
+|---|---|
+| I noticed something interesting (no ask) | `memory/` notebook |
+| I'm stuck and need an answer to continue | `escalations/` with `kind: help` |
+| I see process friction, file-and-forget | `escalations/` with `kind: improvement` |
+| I drafted a new verb | `verbs/proposed/` + `escalations/` with `kind: proposed_skill` |
+| The change I want is on a surface listed in `lib/autonomy.yaml` as autonomous | Edit directly per CLAUDE.md "Autonomous edits" — no escalation needed |
+| I've hit `max_pending` on an append-only surface | `escalations/` with `kind: improvement` asking for compaction |
+
+## What you do
+
+### 1. Pick a slug
+
+Short, kebab-case, descriptive. The slug should hint at the topic without needing to read the body.
+
+### 2. Write the escalation file
+
+Create `escalations/{YYYY-MM-DD}-{slug}.md` (today's date in ISO format). Use this frontmatter:
+
+```yaml
+---
+kind: help | improvement | proposed_skill
+urgency: low | normal | high
+created: YYYY-MM-DD
+agent_context: <which verb run produced this>
+proposed_skill: <optional path to the draft, e.g. "verbs/proposed/{slug}.md">
+status: open
+---
+```
+
+Omit fields that don't apply. `urgency` only really applies to `help`; default `improvement` and `proposed_skill` to `normal`.
+
+### 3. Body
+
+Three sections, in order:
+
+```markdown
+# {Short title}
+
+## What I was doing
+One paragraph. What I was working on, what I expected to happen.
+
+## What I tried
+What steps I took before raising this. For `improvement`, what I observed across runs. For `proposed_skill`, the gap I'm trying to close.
+
+## What I'm asking for
+The actual ask, in one or two sentences.
+```
+
+Be specific. "Help me with this" is too vague. "Should I send the draft despite the public-domain risk, or hold for verification?" is what the operator can act on.
+
+### 4. For `proposed_skill` only — write the draft first
+
+Before filing the escalation:
+
+1. Write the proposed verb prompt at `verbs/proposed/{slug}.md`. Same shape as any verb.
+2. Then file the escalation referencing it.
+
+Don't file a `proposed_skill` escalation without the draft.
+
+### 5. Surface immediately if blocking
+
+If `kind: help` and `urgency: high`, mention the escalation in the response to the operator before signing off. Example:
+
+> "stuck — filed `escalations/2026-05-05-{slug}.md`. need your call before i continue."
+
+For other urgencies and kinds, the dashboard surfaces the queue.
+
+## Hard rules
+
+- NEVER move my own drafts from `verbs/proposed/` to `verbs/`. Acceptance is the operator's call.
+- NEVER edit an existing verb in `verbs/` to "fix" it on my own. File an `improvement` escalation instead.
+- NEVER overwrite an existing escalation. Append a comment block (`<!-- {date}: {observation} -->`) or file a fresh one.
+- NEVER mark `status: accepted` / `declined` on my own drafts.
+- If I have nothing to escalate at end-of-run, that's fine. Don't manufacture escalations.
+
+## Reporting
+
+If I filed escalations during a run, summarise at the end:
+
+```
+escalations:
+- {slug} ({kind}, {urgency}) — {one-line ask}
+```
+
+If urgency is high, lead with this. Otherwise it's a tail-of-report item.