feat(decisions): promote inbound decisions to first-class decision records

AGENTS.md

@@ -4,7 +4,7 @@ Guidance for AI agents (Claude Code, Codex, etc.) working in this repository. `C
 
 ## Project Overview
 
-dotbot is a structured AI-assisted development framework built entirely in **PowerShell 7+**. It wraps AI coding workflows in managed, auditable processes with two-phase execution (analysis → implementation), per-task git worktree isolation, and a web dashboard for monitoring.
+dotbot is a structured AI-assisted development framework built entirely in **PowerShell 7+**. It wraps AI coding workflows in managed, auditable processes with single-session task execution, per-task git worktree isolation, and a web dashboard for monitoring.
 
 ## Commands
 
@@ -61,10 +61,9 @@ The PowerShell framework (`src/runtime/`, `src/mcp/`, `src/ui/`, `src/cli/`, `sr
 
 `src/runtime/Modules/ContentResolver/` implements project-over-framework lookup. A project can override any content item (agents/skills/prompts/workflows/stacks/recipes) by placing it under `<BotRoot>/content/<Type>/`, or override hook scripts by placing them under `<BotRoot>/hooks/<verify|dev|scripts>/`; the runtime falls back to `<DOTBOT_HOME>` otherwise. Merge is by filename — a project file replaces the framework file of the same name; framework-only files still run. APIs: `Resolve-DotbotContent`, `Get-DotbotContentItems`, `Get-DotbotHookChain`.
 
-### Two-phase execution
+### Single-session execution
 
-1. **Analysis** (`98-analyse-task.md`): explores codebase, builds context package, may propose splits. Task: `todo → analysing → analysed`.
-2. **Implementation** (`99-autonomous-task.md`): consumes context, writes code, tests, commits with `[task:XXXXXXXX]` tag. Task: `analysed → in-progress → done`.
+Each task runs in one provider session driven by `100-single-session-task.md`. That session handles discovery, implementation, verification, and commit (with a `[task:XXXXXXXX]` tag), then marks the task done. If human input is needed it pauses on `needs-input` and resumes the same task. Task lifecycle: `todo -> analysing -> analysed -> in-progress -> done`; the task-runner auto-promotes through `analysing`/`analysed` (there is no separate analysis provider session).
 
 ### Git worktree isolation
 

README.md

@@ -17,7 +17,7 @@ dotbot wraps AI-assisted coding in a managed, transparent workflow where every s
 - **Workflows and stacks** - **Workflows** (e.g. `start-from-jira`) define operational pipelines - what dotbot does. **Stacks** (e.g. `dotnet`, `dotnet-blazor`) add tech-specific skills, hooks, and MCP tools - what tech the project uses. Stacks compose additively with `extends` chains. Settings deep-merge across `default -> workflows -> stacks`.
 
 ### Execution engine
-- **Two-phase execution** - Analysis resolves ambiguity, identifies files, and builds a context package. Implementation consumes that package and writes code. Tasks flow: `todo -> analysing -> analysed -> in-progress -> done`.
+- **Single-session execution** - Each task runs in one provider session that does discovery, implementation, verification, and commit, pausing only when human input is needed. Tasks flow: `todo -> analysing -> analysed -> in-progress -> done`.
 - **Per-task git worktree isolation** - Each task runs in its own worktree on an isolated branch, squash-merged back to main on completion.
 - **Per-task model selection** - Tasks can specify a model (e.g. Sonnet for simple tasks, Opus for complex ones) that overrides the process-level default. Use cheaper models where they suffice to reduce token spend.
 - **Multi-slot concurrent execution** - The workflow engine runs multiple tasks from the same workflow in parallel with slot-aware locking, shortening wall-clock time for large task queues.

content/prompts/00-interview.md

@@ -0,0 +1,84 @@
+# Clarification Interview
+
+You are conducting a clarification interview for a software project. The user's
+short project description appears below. Each round, decide one thing: do you
+have enough clarity to proceed, or must you ask the user targeted questions
+first?
+
+Each round you write EXACTLY ONE file to `.bot/workspace/product/`:
+
+- `clarification-questions.json` -- you still need answers. The loop pauses,
+  collects the user's answers, then runs you again with those answers in
+  context.
+- `interview-summary.md` -- you have enough clarity. The interview ends.
+
+NEVER write both in the same round. Do not write any other files (no
+`mission.md`, no `tech-stack.md`). Do not use task-management tools.
+
+## When to ask vs finish
+
+Ask a question only when a genuine ambiguity would change the design, scope, or
+technology AND you cannot resolve it from the description, the briefing files,
+or previous rounds. Finish when the only unknowns left are ordinary
+implementation details a developer can settle later.
+
+If a previous round already answered a question, do NOT re-ask it. Build on the
+answer.
+
+## clarification-questions.json schema
+
+The loop validates this file strictly. A malformed file fails the task. Match
+this shape exactly:
+
+{
+  "questions": [
+    {
+      "id": "q1",
+      "question": "One clear, specific question. Do not inline the choices here.",
+      "context": "Why this matters -- what is ambiguous and what the answer changes.",
+      "options": [
+        { "key": "A", "label": "First option, short noun phrase", "rationale": "Why you might pick this" },
+        { "key": "B", "label": "Second option", "rationale": "Why you might pick this" }
+      ],
+      "recommendation": "A"
+    }
+  ]
+}
+
+Hard rules (the validator rejects the file otherwise):
+
+- `questions` is a non-empty array.
+- Each question has a non-empty `question` string.
+- `options` is REQUIRED and is an array of OBJECTS. Never plain strings. Never
+  inline the choices as text in the `question` field.
+- Each option is an object with `key` and `label`. `key` is a single uppercase
+  letter: A, B, C, D, or E, unique within the question. `label` is a non-empty
+  short phrase. `rationale` is optional but recommended.
+- Each question has 2 to 5 options.
+- `recommendation`, if present, must equal one of the option keys. Put the
+  recommended choice as option `A`.
+- `context` is optional but recommended.
+
+Ask only as many questions as genuinely needed. Fewer, sharper questions beat
+many shallow ones.
+
+## interview-summary.md format
+
+When you have enough clarity, write a short markdown summary:
+
+# Interview Summary
+
+## Project
+One paragraph restating what is being built.
+
+## Key Decisions
+- Bullet the choices that are now settled (from the description, the briefing,
+  or answered questions).
+
+## Clarification Log
+One row per answered question across all rounds. Omit this whole section if no
+questions were ever asked.
+
+| # | Question | Answer | Interpretation |
+|---|----------|--------|----------------|
+| q1 | ... | ... | ... |

content/prompts/100-single-session-task.md

@@ -12,12 +12,12 @@ You are an autonomous AI coding agent. Complete this task in the current provide
 
 Built-in tools (`Read`, `Write`, `Edit`, `Bash`, `Glob`, `Grep`, `WebSearch`, `WebFetch`) are always available. Do not use ToolSearch for them.
 
-The Bash tool runs Bash, not PowerShell. If you need PowerShell semantics, run `pwsh -Command "<script>"` explicitly.
+The Bash tool runs Bash, not PowerShell. Do not use `$obj.property`, `$_.Name`, `Get-ChildItem`, or `Where-Object`. Use `jq` for JSON, `awk` or `cut` for fields, `$(command)` for substitution, `grep` and `find` for filtering. If you need PowerShell semantics, run `pwsh -Command "<script>"` explicitly.
 
 Load dotbot tools once:
 
 ```
-ToolSearch({ query: "select:mcp__dotbot__task_get_context,mcp__dotbot__task_set_status,mcp__dotbot__task_update,mcp__dotbot__plan_get,mcp__dotbot__plan_create,mcp__dotbot__task_mark_needs_review,mcp__dotbot__steering_heartbeat" })
+ToolSearch({ query: "select:mcp__dotbot__task_get_context,mcp__dotbot__task_set_status,mcp__dotbot__task_update,mcp__dotbot__plan_get,mcp__dotbot__plan_create,mcp__dotbot__task_mark_needs_review,mcp__dotbot__steering_heartbeat,mcp__dotbot__decision_list,mcp__dotbot__decision_get" })
 ```
 
 If the exact `select:` query returns no schemas, wait briefly and retry the exact same query once. Do not broaden the search.
@@ -75,6 +75,26 @@ If `resume_context` is present:
 
 If `resume_context` is absent, do focused discovery only. Read the smallest useful set of files before editing.
 
+## Decisions
+
+Accepted decisions are binding constraints. Honour them while you implement; do not contradict or re-litigate them.
+
+After `task_get_context` returns:
+
+1. If the task has `applicable_decisions` set, read each one:
+
+   ```
+   mcp__dotbot__decision_get({ decision_id: "dec-XXXXXXXX" })
+   ```
+
+2. If `applicable_decisions` is empty, list accepted decisions and keep the ones whose `decision` or `consequences` bear on this task's entities or category:
+
+   ```
+   mcp__dotbot__decision_list({ status: "accepted" })
+   ```
+
+The list also contains **inbound decisions** (tagged `inbound:mothership`, `inbound:registry`, or `inbound:settings`) captured from external answers, workflow changes, and settings changes. Treat them the same as locally-authored decisions. The log is append-only and grows over time, so filter by relevance: include an inbound decision only when its `related_task_ids` names this task, or its `decision`/`consequences` clearly bears on this task. Apply each relevant decision's `decision` and `consequences` as a hard constraint.
+
 ## Working Directory
 
 You are in a task worktree on branch `{{BRANCH_NAME}}`. Commit to this branch and do not push. The framework squash-merges it.