hatch3r 1.9.0 → 2.0.0

package/dist/content/{commands/hatch3r-hooks.md → skills/hatch3r-hooks/SKILL.md}

@@ -1,38 +1,37 @@
 ---
 id: hatch3r-hooks
-type: command
-orchestrator: false
-description: Define and manage event-driven hooks that activate agents on project events
+name: hatch3r-hooks
+type: skill
+description: Define, edit, and manage event-driven hooks that activate agents on project events. Tool-agnostic — adapters translate hook definitions into tool-native configurations during `npx hatch3r sync`.
 tags: [devops, orchestration]
 quality_charter: agents/shared/quality-charter.md
 efficiency_patterns: agents/shared/efficiency-patterns.md
 cache_friendly: true
-parallel_tool_default: true
 ---
 
-## §0 Detect Ambiguity (P8 B1)
+# Hooks — Event-Driven Agent Activation
 
-Before any action, scan the user's request and provided context for unresolved questions in scope, acceptance criteria, irreversibility, or constraint conflicts (contradictory inputs, missing target, unknown convention). If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md` — do not proceed under silent assumption. This is the default path, not an exception. Acceptable to proceed without asking ONLY when scope is single-target, single-concern, and the brief alone is testable. Any residual ambiguity discovered mid-workflow invokes the same protocol.
+## Quick Start
 
-## Agent Pipeline
+```
+Task Progress:
+- [ ] Step 0: Detect ambiguity (P8 B1)
+- [ ] Step 1: Discover current state
+- [ ] Step 2: Define a hook (add) — select event, agent, conditions, write definition file
+- [ ] Step 3: Edit an existing hook
+- [ ] Step 4: Remove a hook
+- [ ] Step 5: Sync hooks to tools
+```
 
-This command runs as a single orchestrator without sub-agent delegation. Hook definition and management are performed inline.
+## Step 0 — Detect Ambiguity (P8 B1)
+
+Before any action, scan the user's request and provided context for unresolved questions in scope, acceptance criteria, irreversibility, or constraint conflicts (contradictory inputs, missing target, unknown convention). If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md` — do not proceed under silent assumption. This is the default path, not an exception. Acceptable to proceed without asking ONLY when scope is single-target, single-concern, and the brief alone is testable. Any residual ambiguity discovered mid-workflow invokes the same protocol.
 
 ## Learnings Consultation
 
 If `.hatch3r/learnings/` exists, scan for learnings related to hook configurations, event trigger patterns, or prior hook issues before starting.
 
-# Hooks — Event-Driven Agent Activation
-
-Define, edit, and manage event-driven hooks that automatically activate hatch3r agents when specific project events occur. Hook definitions are tool-agnostic — the adapter pipeline translates them into tool-native configurations during `npx hatch3r sync`.
-
----
-
-## Workflow
-
-Execute these steps in order. **Do not skip any step.** Ask the user at every checkpoint marked with ASK.
-
-### Step 1: Discover Current State
+## Step 1: Discover Current State
 
 1. Check `hooks/` for existing hook definition files (`.md` files with frontmatter).
 2. Read `.hatch3r/hatch.json` for configured tools and features.
@@ -48,13 +47,11 @@ Hooks Feature: {enabled/disabled}
 
 **ASK:** "Current hooks: {list or 'none'}. Tools: {list}. What would you like to do? (a) Add a new hook, (b) Edit existing hook, (c) Remove a hook, (d) List all hooks, (e) Sync hooks to tools"
 
----
-
-### Step 2: Define Hook
+## Step 2: Define Hook
 
 For adding a new hook:
 
-#### 2a. Select Event
+### 2a. Select Event
 
 Present available events with descriptions:
 
@@ -79,19 +76,22 @@ Present available events with descriptions:
 | `on-dependency-change` | Triggered when dependencies are added/updated/removed | Security audit, compatibility check, license validation |
 | `on-security-finding` | Triggered when a security issue is discovered | Alert escalation, auto-fix suggestions, incident creation |
 
+> [!IMPORTANT]
+> Claude Code only maps `session-start` → `SessionStart` semantically. Every other event above (pre-commit, post-merge, ci-failure, file-save, pre-push, etc.) is a git/project lifecycle event with NO native Claude Code mapping — the adapter emits a no-op or alternative strategy, NOT a PreToolUse/PostToolUse binding. If the user picks one of these and targets Claude Code, say so before writing the definition. Full detail: the "Claude Code event mapping" note in Step 2d below.
+
 **ASK:** "Select an event for this hook."
 
-#### 2b. Select Agent
+### 2b. Select Agent
 
 Present available hatch3r agents:
 
 - `lint-fixer` — Automatic lint error resolution
-- `test-writer` — Test generation for new or changed code
+- `hatch3r-testability` — Test generation for new or changed code
 - `reviewer` — Code review and quality checks
-- `security-auditor` — Security vulnerability scanning
+- `hatch3r-security` — Security vulnerability scanning
 - `ci-watcher` — CI/CD pipeline monitoring and diagnosis
 - `a11y-auditor` — Accessibility compliance checks
-- `perf-profiler` — Performance analysis and optimization
+- `hatch3r-performance` — Performance analysis and optimization
 - `dependency-auditor` — Dependency security and update checks
 - `docs-writer` — Documentation generation and updates
 
@@ -99,14 +99,14 @@ If the user wants a custom agent name not in this list, accept it but warn that
 
 **ASK:** "Select an agent to activate when this event fires."
 
-#### 2c. Define Conditions (Optional)
+### 2c. Define Conditions (Optional)
 
 - **Glob patterns:** Which files trigger this hook (e.g., `src/**/*.ts`, `*.css`)
 - **Branch patterns:** Which branches (e.g., `main`, `release/*`)
 
 **ASK:** "Add conditions? (glob patterns, branch patterns, or skip for 'always activate')"
 
-#### 2d. Write Hook Definition File
+### 2d. Write Hook Definition File
 
 Generate the hook definition file at `hooks/{event}-{agent-short-name}.md`:
 
@@ -141,9 +141,7 @@ Claude Code event mapping: **Claude Code's native hook events (PreToolUse, PostT
 
 **ASK:** "Hook definition: {summary}. Create? (yes / adjust / cancel)"
 
----
-
-### Step 3: Edit Existing Hook
+## Step 3: Edit Existing Hook
 
 For editing an existing hook:
 
@@ -154,9 +152,7 @@ For editing an existing hook:
 
 **ASK:** "Updated hook: {summary}. Save? (yes / revert / cancel)"
 
----
-
-### Step 4: Remove a Hook
+## Step 4: Remove a Hook
 
 1. List all hooks and ask which to remove.
 2. Show the hook definition.
@@ -165,9 +161,7 @@ For editing an existing hook:
 
 3. Delete the file. Warn that tool-specific generated files (e.g., `.cursor/rules/hatch3r-hook-*.mdc`) will be cleaned up on the next `npx hatch3r sync`.
 
----
-
-### Step 5: Sync Hooks to Tools
+## Step 5: Sync Hooks to Tools
 
 1. Read all hook definitions from `hooks/`.
 2. For each configured tool in `hatch.json`, describe what will be generated:
@@ -176,111 +170,28 @@ For editing an existing hook:
    - **Others:** No-op (hook definitions stored for future adapter support)
 3. Present the list of files that will be generated/updated.
 
+> [!IMPORTANT]
+> For Claude Code, only `session-start` becomes an executable native hook. Git/project-event hooks (pre-commit, post-merge, ci-failure, file-save, pre-push, etc.) are written to `CLAUDE.md` as documentation, NOT registered as native Claude Code hooks — they do not fire on the named event. State this explicitly when listing the generated Claude Code output (see the "Claude Code event mapping" note in Step 2d).
+
 **ASK:** "Hooks will generate these files: {list}. Run `npx hatch3r sync` to apply. (understood / sync now)"
 
 If user chooses "sync now", instruct them to run `npx hatch3r sync` in the terminal.
 
----
-
-## Custom Events
-
-Define project-specific hook events beyond the built-in types:
+## Hook Definition Schema (implemented surface)
 
-- **Event naming**: `custom:{domain}:{action}` (e.g., `custom:billing:subscription-change`)
-- **Event registration**: Add custom events to `hatch.json` under `hooks.customEvents`
-- **Event triggering**: Agents trigger custom events via `emit-hook custom:{name}` in their workflows
-- **Event payload**: Custom events can pass structured data to hook handlers via JSON payload
+A hook is a single canonical artifact: one event fires one agent, optionally narrowed by conditions. The fields below are the complete config that adapters honor today (`src/hooks/types.ts` `HookDefinition` + `HookCondition`):
 
-### Custom Event Definition
+| Field | Required | Meaning |
+|-------|----------|---------|
+| `id` | yes | Unique hook identifier (sanitized for shell safety). |
+| `event` | yes | Lifecycle event from the events table in Step 2a. |
+| `agent` | yes | Agent ID dispatched when the event fires. |
+| `description` | yes | Human-readable purpose. |
+| `globs` | no | File glob patterns — hook fires only when matching files are affected. |
+| `branches` | no | Branch name patterns — hook fires only on matching branches. |
+| `labels` | no | Issue/PR labels — hook fires only when matching labels are present. |
 
-In `hatch.json`:
-
-```json
-{
-  "hooks": {
-    "customEvents": [
-      {
-        "name": "custom:billing:subscription-change",
-        "description": "Fired when a subscription plan changes",
-        "payload": { "userId": "string", "oldPlan": "string", "newPlan": "string" }
-      }
-    ]
-  }
-}
-```
-
-Custom events follow the same hook definition format as built-in events — create a hook file in `hooks/` with `event: custom:{domain}:{action}`.
-
----
-
-## Hook Chaining
-
-Hooks can trigger other hooks in sequence:
-
-- **Chain definition**: Define ordered hook chains in `hatch.json` under `hooks.chains`
-- **Execution order**: Hooks in a chain execute sequentially; failure in any hook stops the chain
-- **Error handling**: Chain-level error handlers can catch and handle failures from individual hooks
-- **Conditional chaining**: Hooks can conditionally trigger next hook based on output (pass/fail/skip)
-
-### Chain Definition
-
-In `hatch.json`:
-
-```json
-{
-  "hooks": {
-    "chains": [
-      {
-        "id": "pre-release-pipeline",
-        "description": "Full pre-release validation chain",
-        "steps": [
-          { "hook": "pre-release-security-auditor", "on_fail": "stop" },
-          { "hook": "pre-release-test-writer", "on_fail": "stop" },
-          { "hook": "pre-release-docs-writer", "on_fail": "warn" }
-        ],
-        "on_error": "notify"
-      }
-    ]
-  }
-}
-```
-
-Chains are triggered by referencing the chain ID as the hook target. Individual hook results (`pass`, `fail`, `skip`) determine whether the chain continues.
-
----
-
-## Hook Execution Ordering
-
-When multiple hooks are registered for the same event:
-
-- **Priority**: Hooks have a priority field (1-100, lower runs first, default 50)
-- **Parallel vs Sequential**: Hooks at the same priority level run in parallel; different priority levels run sequentially
-- **Timeout**: Each hook has a configurable timeout (default 30 seconds). Timed-out hooks are reported as failures.
-- **Isolation**: Each hook runs in its own context. Hook outputs are collected but don't affect other hooks unless chained.
-
-### Priority Configuration
-
-Add `priority` and `timeout` to hook frontmatter:
-
-```markdown
----
-id: my-pre-commit-lint-fixer
-type: hook
-event: pre-commit
-agent: lint-fixer
-priority: 10
-timeout: 60
----
-```
-
-### Execution Example
-
-For `pre-commit` with three hooks:
-1. `lint-fixer` (priority 10) — runs first
-2. `security-auditor` (priority 20) — runs second
-3. `test-writer` (priority 50) and `reviewer` (priority 50) — run in parallel, third
-
----
+There is no chaining, custom-event, priority, timeout, or parallel-by-priority config: each hook is independent, the adapter emits one tool-native entry per hook, and ordering across multiple hooks on the same event is the tool's own (Claude Code stacks matcher entries; Cursor stacks `.cursor/hooks.json` entries). Do not author `hooks.chains`, `hooks.customEvents`, `emit-hook`, `priority:`, or `timeout:` — no code consumes them.
 
 ## Error Handling
 
@@ -297,5 +208,5 @@ For `pre-commit` with three hooks:
 - Never delete hook files without explicit user confirmation.
 - Always validate event names against the known events list.
 - Hook IDs must be unique across all hook definitions.
-- The command creates hook DEFINITIONS only — actual hook registration happens via `npx hatch3r sync`.
+- The skill creates hook DEFINITIONS only — actual hook registration happens via `npx hatch3r sync`.
 - Do not modify adapter output files directly — they are managed by the sync pipeline.

package/dist/content/skills/hatch3r-incident-response/SKILL.md

@@ -1,6 +1,8 @@
 ---
 id: hatch3r-incident-response
-description: Handle production incidents with structured triage, mitigation, and post-mortem. Use when responding to production issues, outages, or security incidents.
+name: hatch3r-incident-response
+type: skill
+description: Handles production incidents with structured triage, mitigation, and post-mortem. Use when responding to production issues, outages, or security incidents.
 tags: [devops]
 quality_charter: agents/shared/quality-charter.md
 efficiency_patterns: agents/shared/efficiency-patterns.md
@@ -8,12 +10,23 @@ cache_friendly: true
 ---
 # Incident Response Workflow
 
+## Relationship to `commands/hatch3r-incident-response.md` (Decision 13 handoff)
+
+This skill shares the `id: hatch3r-incident-response` with the orchestrator command `commands/hatch3r-incident-response.md`. The two are NOT duplicates — they split the incident workflow by execution model per CONSTITUTION §6 Decision 13:
+
+- **`commands/hatch3r-incident-response.md` (orchestrator entry):** the delegated live-incident pipeline — a hatch3r-incident-responder specialist drives triage → bounded-autonomy mitigation → communication → blameless post-mortem, and a hatch3r-reliability specialist runs the post-incident telemetry/SLO reconstruction in parallel once stabilized (`agentPipeline: [hatch3r-incident-responder, hatch3r-reliability]`). Use the command for a live production incident that warrants specialist fan-out (parallel mitigation + reliability reconstruction); a security-suspected incident adds hatch3r-security.
+- **This skill (inline procedure):** the single-pass reference body the responder follows for the classify → topology → triage → mitigate → root-cause → post-mortem sequence. Use the skill directly for a Tier 1 single-service incident where no fan-out is needed, OR as the step-by-step procedure the command's incident-responder stage executes.
+- **Unique to this skill:** the Bounded Autonomy & Escalation matrix (auto-action vs human-gate threshold by severity) and the Telemetry Sources adapter (signal-by-capability-class) are the inline-procedure detail the command references rather than restates.
+
+The merge-candidate review (F16.3-H3) flagged the shared id; this handoff documentation is the explicit workflow-split declaration that disambiguates the pair, enforced by the Decision-13 command↔skill gate in `src/cli/commands/validate.ts`. A future collapse into a single command appendix requires coordinated edits to the command body, the bundled content inventory (skills count), and that gate.
+
 ## Quick Start
 
 ```
 Task Progress:
 - [ ] Step 0: Detect ambiguity (P8 B1)
 - [ ] Step 1: Classify severity (P0-P3) based on impact
+- [ ] Step 1b: Capture topology context — impacted service graph + upstream/downstream deps
 - [ ] Step 2: Triage — identify affected systems, user impact, blast radius
 - [ ] Step 3: Mitigate — apply hotfix or rollback, verify mitigation works
 - [ ] Step 4: Root cause analysis — trace the failure chain
@@ -21,18 +34,47 @@ Task Progress:
 - [ ] Step 6: Create follow-up issues for permanent fixes and preventive measures
 ```
 
+Two policies bound this workflow before any remediation action runs: the **Bounded Autonomy & Escalation** matrix (which actions auto-execute vs require a human gate, by severity) and the **Telemetry Sources** adapter (where to read signal, by capability class). Both are defined below; read them before Step 3.
+
 ## Step 0 — Detect Ambiguity (P8 B1)
 
 Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per `agents/shared/user-question-protocol.md`. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: user-facing impact vs internal-only, blast radius known (single tenant vs all users), rollback safety verified, stakeholder notification scope (engineering vs exec vs public), and whether mitigation requires data write (irreversible) vs config flip (reversible).
 
 ## Fan-out Discipline (P8 B2)
 
-This skill delegates per task size:
-- Tier 1 (trivial single-file): inline execution acceptable.
-- Tier 2 (multi-file or multi-concern): spawn parallel sub-agents per concern via the Task tool.
-- Tier 3 (multi-module / high-risk): one fresh sub-agent per independent module or gate; orchestrator integrates only.
+Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Emit `sub_agents_spawned: { count, rationale }` in your output.
+
+## Bounded Autonomy & Escalation
+
+An agent acting in a live incident operates under bounded autonomy: actions are bounded, reversible-first, and gated on a human-in-the-loop for high-blast-radius severities. This matrix sets the auto-action vs escalation threshold by severity. Match the row to the severity assigned in Step 1.
+
+| Severity | Autonomy bound | Required gate before action |
+| -------- | -------------- | --------------------------- |
+| P0 | No autonomous mutation. Investigate, build the timeline, propose a diff — do not apply. | Human approval required before any mitigation. Page on-call; do not self-execute. |
+| P1 | Confidence-routed. High-confidence reversible action (flag flip, scale-up, documented rollback) may auto-apply WITH a diff preview emitted first; low-confidence or irreversible action escalates. | Human gate when confidence is medium/low OR the action writes data / is irreversible. |
+| P2 | Auto-remediation acceptable for reversible actions with a diff preview emitted before apply. | Human gate only for irreversible (data-write, schema, destructive) actions. |
+| P3 | Auto-remediation acceptable. | None for reversible actions; flag irreversible actions for review. |
+
+Rules that hold across all rows:
+
+- **Reversibility-first.** Prefer the reversible mitigation (feature-flag flip, config revert, scale-up, deploy rollback) over an irreversible one (data write, schema change). An irreversible action escalates one severity band on the gate column.
+- **Diff preview before apply.** Any auto-applied mutation emits the exact change (command, flag, config delta) before execution, never after.
+- **Confidence routing.** State confidence (high/medium/low per `agents/shared/quality-charter.md` section 1) on every proposed mitigation. Medium/low confidence on P1 routes to a human gate.
+- **Audit trail.** Every action (auto or gated) is recorded in the incident timeline (Step 5) with actor, timestamp, and the gate decision.
 
-Never under-fan-out to save tokens. Token cost is dominated by quality and completeness gains. Emit `sub_agents_spawned: { count, rationale }` in your output.
+## Telemetry Sources
+
+Capture signal from the project's observability stack before declaring blast radius (Step 1b) and when verifying mitigation (Step 3). Read the configured stack from project conventions; do not assume a vendor. Adapter patterns by capability class:
+
+| Capability class | What to read | Common providers |
+| ---------------- | ------------ | ---------------- |
+| Distributed traces | Request path spans, `trace_id`/`span_id` correlation, latency percentiles | OpenTelemetry-compatible backend, Datadog APM, Grafana Tempo |
+| Metrics (RED/USE) | Rate, Errors, Duration per route; Utilization, Saturation, Errors per resource | Prometheus/Grafana, CloudWatch, Datadog |
+| Logs | Structured JSON with `trace_id`, service+version+environment, error-level stack traces | Splunk, CloudWatch Logs, Loki |
+| Error tracking | Grouped exceptions with release + environment tags | Sentry-class tracker |
+| Deploy/change history | Recent deploys, config changes, dependency bumps correlated to incident start | Platform CLI (`gh`/`az`/`glab`), CI deploy log |
+
+Reference `rules/hatch3r-observability-tracing.md` and `rules/hatch3r-observability-logging.md` for the end-user instrumentation floor these sources read from. When a capability class is not instrumented in the project, record the gap as a post-mortem action item rather than assuming data exists.
 
 ## Step 1: Classify Severity
 
@@ -49,6 +91,17 @@ Never under-fan-out to save tokens. Token cost is dominated by quality and compl
   - **GitLab:** `glab issue list --search "..."` or `glab issue view N`
 - For external library docs and current best practices, follow the project's tooling hierarchy.
 
+## Step 1b: Capture Topology Context
+
+Before declaring blast radius in Step 2, map the impacted service graph. A correct blast-radius estimate depends on knowing what the failing component talks to — upstream callers amplify user impact, downstream dependencies are candidate root causes.
+
+1. **Identify the impacted node(s):** which service, function, or resource is emitting the failure signal (from the Telemetry Sources above).
+2. **Trace upstream:** which services/clients call the impacted node? These define the user-facing blast radius — a failure in a shared dependency fans out to every caller.
+3. **Trace downstream:** which dependencies does the impacted node call (database, queue, third-party API, RPC peer)? A downstream failure is a candidate root cause, not a symptom site.
+4. **Record the graph:** capture the upstream/downstream edges (from distributed traces, a service catalog, or an architecture ADR in project docs) before estimating blast radius. If no service map exists, reconstruct it from trace spans and note the absence as a post-mortem action item.
+
+Output a one-line topology summary: `impacted: {node} | upstream callers: {list} | downstream deps: {list}`. Step 2 blast-radius estimation consumes this directly.
+
 ## Step 2: Triage
 
 - **Affected systems:** Frontend, backend, database, auth, payment, third-party services?
@@ -61,7 +114,8 @@ Never under-fan-out to save tokens. Token cost is dominated by quality and compl
 
 - **Immediate actions:** Rollback last deploy, disable feature flag, revert config, scale up, or apply hotfix.
 - **Verification:** Confirm mitigation works — error rate drops, affected flow recovers.
-- **Communication:** Notify stakeholders if P0/P1. Document status in incident channel or issue.
+- **Communication:** Notify stakeholders per the page-target SLA below. Document status in incident channel or issue.
+  - Default page-target by severity (tune per org): P0 — page on-call ≤5 min after detection; P1 — ≤15 min; P2 — ≤1 h; P3 — next business day.
 - Do not spend time on perfect fixes during active incident — stabilize first.
 
 ## Step 4: Root Cause Analysis
@@ -113,3 +167,8 @@ Store in project incident docs or as an issue/wiki page on the platform. Follow
 - Privacy/security specs: project documentation
 - Observability: project logging and correlation conventions
 - Error handling: project error handling patterns
+
+## References
+
+- [Managing Incidents — Google SRE Book, ch. 14](https://sre.google/sre-book/managing-incidents/) — accessed 2026-05-31, official-docs (Google SRE). Source for the severity-tiered incident command structure and the timeline / post-mortem discipline in Steps 1–5.
+- [Monitoring distributed systems (RED / USE / four golden signals) — Google SRE Book, ch. 6](https://sre.google/sre-book/monitoring-distributed-systems/) — accessed 2026-05-31, official-docs (Google SRE). Source for the RED/USE metric classes in the Telemetry Sources adapter and the blast-radius signal capture in Step 1b.

package/dist/content/skills/hatch3r-issue-workflow/SKILL.md

@@ -1,5 +1,7 @@
 ---
 id: hatch3r-issue-workflow
+name: hatch3r-issue-workflow
+type: skill
 description: Guides the 8-step agentic development workflow for issues/work items. Covers parsing issues, loading skills, reading specs, planning, implementing, testing, opening PRs/MRs, and addressing review. Use when working on any issue/work item or when the user mentions an issue number.
 tags: [implementation, orchestration]
 quality_charter: agents/shared/quality-charter.md
@@ -121,6 +123,15 @@ Skip this step if the issue has no user-facing UI changes.
 - Push fixes as new commits (don't force-push during review).
 - Re-request review after addressing all comments.
 
+## Fan-out Discipline (P8 B2)
+
+Fan-out scales with task size; token cost never justifies serializing independent work (`rules/hatch3r-fan-out-discipline.md` P8 B2; `agents/shared/efficiency-patterns.md`). Tier boundaries for THIS skill:
+- Tier 1 (trivial single-file issue): inline.
+- Tier 2 (multi-file or multi-concern issue): spawn parallel sub-agents per concern (researcher, implementer, reviewer) via the Task tool.
+- Tier 3 (multi-module / high-risk issue): one fresh sub-agent per independent module or gate; orchestrator integrates only.
+
+Emit `sub_agents_spawned: { count, rationale }` in your output.
+
 ## Error Handling
 
 - **Issue description is too vague to implement**: Do not guess. Ask the user for clarification on acceptance criteria, scope boundaries, and expected behavior before starting Step 3 (planning).