feat(bin): unify design tasks into one planning conversation

.agents/skills/design-profile/SKILL.md

@@ -1,52 +1,65 @@
 ---
 name: design-profile
-description: Agent-only supervisor contract for dispatching and supervising an interactive design task whose tracked deliverable is an ADR. Load before scaffolding, dispatching, answering, completing, or cleaning up a kind=design task.
+description: Agent-only supervisor contract for dispatching and supervising a one-conversation design task whose tracked deliverable is a short ADR. Load before scaffolding, dispatching, answering, completing, or cleaning up a kind=design task.
 user-invocable: false
 metadata:
   internal: true
 ---
 
 # Design Profile
 
-Use this profile when the requested product is an interactive decision process ending in an architectural decision record.
+Use this profile when the requested product is one planning conversation ending in a short architectural decision record.
 Use a ship when implementation is already authorized and remaining design uncertainty cannot materially change what to build.
 Use a scout when the result is knowledge or a recommendation rather than a tracked ADR.
+Do not stack a Kun research pass, a Matt interview, and an ADR task as three workflows.
+Do not add a design interview or visual review in front of well-specified authorized implementation.
+Do not rewrite a live task's already generated brief; this contract applies at the next scaffold and dispatch.
 
-`bin/fm-brief.sh --design` owns the worker-facing interview and ADR contract.
+`bin/fm-brief.sh --design` owns the worker-facing planning and ADR contract.
 `bin/fm-spawn.sh --design` owns task-kind metadata, delivery posture, branch identity, and verified harness launch.
 This skill owns the supervisor decisions around those mechanics.
 
+## One planning conversation
+
+Keep research, optional visual proposals, selective questioning, and the ADR in the same design task.
+Research facts from the repository and established evidence before asking anyone a decision.
+When an ambiguous choice is clearer as a diagram or interactive proposal, the worker may use `lavish-axi` in this conversation.
+Visual review is optional and never a completion gate for a well-specified ADR ask.
+Do not open a separate visual-review scout unless the captain asked for that knowledge deliverable.
+
+Use the dispatch-pinned Matt `grilling` skill only for its design-tree and frontier: ask the next unblocked decision.
+Firstmate's one-keyed-question protocol takes precedence over grilling's "ask the whole frontier in one round".
+Use the dispatch-pinned `domain-modeling` skill to sharpen terms and to judge whether an ADR is warranted.
+Do not import that plugin's `grill-with-docs`, `to-spec`, `to-tickets`, `wayfinder`, `implement`, or `CONTEXT.md` lifecycle.
+Its `to-tickets` is firstmate's backlog plus `bin/fm-brief.sh`.
+Its `implement` is firstmate's ship task and its selected delivery mode.
+Its `code-review` is firstmate's own validation pipeline.
+Importing those would give one contract two owners.
+
 ## Dependency boundary
 
-The profile uses the installed `mattpocock-skills@mattpocock` plugin.
+The profile uses the installed `mattpocock-skills@mattpocock` plugin as thinking tools, not as a second planner.
 `bin/fm-design-skills.sh` is the single owner of resolving named skills from that plugin.
 It only reads the registry and skill files.
 It never installs, updates, copies, vendors, pins, or modifies the plugin.
-Only the captain upgrades that dependency through their own `/plugin` action.
+Workers never own plugin lifecycle.
+Plugin install and refresh are captain-owned outside this repository; do not add a competing updater here.
 
 Run `bin/fm-design-skills.sh check` before scaffolding.
-If it refuses because the install or a required skill is absent, stop and ask the captain to refresh the plugin.
+If it refuses because the install or a required skill is absent, stop and report that the captain-owned plugin install needs a refresh.
 Never substitute copied skill text or run an installer from a worker.
 
-That plugin auto-updates, so `fm-spawn.sh --design` resolves it once at dispatch, binds the worker-facing brief to that result's exact skill paths, and records the release in task metadata so the durable completion manifest carries it past cleanup ([`docs/fleet-data-contracts.md`](../../../docs/fleet-data-contracts.md#the-design-tasks-plugin-release)).
+The installed plugin can change between tasks, so `fm-spawn.sh --design` resolves it once at dispatch, binds the worker-facing brief to that result's exact skill paths, and records the release in task metadata so the durable completion manifest carries it past cleanup ([`docs/fleet-data-contracts.md`](../../../docs/fleet-data-contracts.md#the-design-tasks-plugin-release)).
 A design result that surprises you is therefore traceable to the exact instructions that informed it.
 Do not repeat that release in the ADR: the manifest owns the fact, and the ADR is a project deliverable rather than a record of firstmate's tooling.
 
 When the captain names that plugin's skills for a task, read the resolved `ask-matt` file first and choose on its evidence, rather than reaching for whichever of its skills happens to be visible.
 Account for the choice in the same reply that reports what is being dispatched: which skills were selected and why.
 The router recommends skills that are not invokable as skills.
 Reaching one means resolving its path and reading the file, exactly as the design brief already does for grilling and domain-modeling.
+Select only thinking tools that serve this one conversation; do not dispatch a second Matt workflow.
 
-Do not import that plugin's lifecycle, file layout, or scratch-tracker conventions.
-Its `to-tickets` is firstmate's backlog plus `bin/fm-brief.sh`.
-Its `implement` is firstmate's ship task and its selected delivery mode.
-Its `code-review` is firstmate's own validation pipeline.
-Its `CONTEXT.md` is refused outright by this profile's ADR-only rule.
-Importing those would give one contract two owners.
-The router is for choosing that plugin's thinking tools.
-Firstmate's lifecycle stays firstmate's.
-
-The worker brief tells every harness to read the resolved skill files directly.
+The worker brief tells every harness to read the dispatch-pinned skill files directly.
 This avoids depending on harness-specific command spelling while preserving one exact installed dependency for Claude, Codex, and Pi.
 Those dependencies supply thinking tools only.
 The profile's ADR-only contract takes precedence over any dependency direction to create or update `CONTEXT.md`.
@@ -69,6 +82,7 @@ Restart a live design worker with `bin/fm-control.sh relaunch`, which keeps `kin
 The design worker investigates factual questions from repository evidence and asks one decision question at a time.
 Every question carries a stable key, evidence, and a recommended answer.
 The worker stops until firstmate returns an answer with the same key.
+Preserve that keyed inventory for in-flight design tasks as well as new ones.
 
 Load `ask-user-authority` before answering any design question.
 An answer that follows directly from accepted intent, repository evidence, an established rule, or a decision already returned in the same session is a correction within accepted intent.
@@ -80,6 +94,11 @@ When the interview has converged, require the worker to state the resulting deci
 
 ## ADR completion
 
+Commit a short ADR only when the dispatched domain-modeling skill's ADR bar is met: hard to reverse, surprising without context, and a real trade-off.
+Routine configuration changes are ships, not ADRs.
+If a design interview shows the change does not meet that bar, stop for a keyed decision rather than padding a ceremonial ADR.
+Existing in-flight ADR work keeps its already generated brief and continues to delivery.
+
 Use an existing project ADR convention when one exists.
 Otherwise the worker uses `docs/adr/NNNN-<slug>.md`, incrementing the highest existing number.
 The ADR must stand alone with context, decision, rationale, relevant alternatives, and non-obvious consequences.

AGENTS.md

@@ -315,9 +315,12 @@ A brain result is a nearest indexed page, not an answer: a miss is absence of a
 Classify the deliverable:
 
 - **Ship** is the default and produces an authorized project change through the selected delivery mode; once implementation is authorized, dispatch a ship and keep any remaining bounded research inside it unless unresolved uncertainty could materially change whether or what to build.
-- **Design** runs an interactive decision interview whose only tracked project change is an ADR; load `design-profile` before scaffolding, dispatching, answering, completing, or cleaning up one.
+- **Design** is an explicit ADR task for a consequential architectural tradeoff whose only tracked project change is that ADR; load `design-profile` before scaffolding, dispatching, answering, completing, or cleaning up one.
 - **Scout** produces knowledge in `data/<id>/report.md`, never a PR, and is appropriate for investigation, diagnosis, planning, reproduction, or audit work when the captain explicitly requests a separate knowledge deliverable or unresolved uncertainty could materially change whether or what to build.
 
+Keep planning in one conversation: research and optional visual proposals where they change the decision, and selective dependency-aware questioning, rather than stacking separate Kun, Matt, and ADR workflows.
+Do not add a design interview or visual review in front of already authorized, well-specified implementation.
+Routine configuration changes are ships, not ADRs.
 If established evidence already answers an informational question, relay it without a design-only scout; when implementation intent is unclear, answer and ask one concise implementation question when useful rather than dispatching speculative design work.
 Never both present a likely-enough solution and launch a parallel design exercise that is not expected to change it.
 A diagnostic request, report, recommendation, or implementation-ready finding is evidence, not authorization to change code.
@@ -424,7 +427,7 @@ Retire one only on an explicit captain or main-firstmate decision, after loading
 ### Design outcome
 
 A completed design task leaves a tracked ADR and no implementation.
-Load `design-profile` before treating the ADR as complete; it owns the interview, dependency boundary, harness-independent skill resolution, decision inventory, delivery, and cleanup contract.
+Load `design-profile` before treating the ADR as complete; it owns the one-conversation planning contract, dependency boundary, harness-independent skill resolution, decision inventory, delivery, and cleanup.
 
 ### Scout outcome and promotion
 
@@ -593,7 +596,7 @@ These skills are not captain-invocable; load them only at their precise triggers
 
 - `bootstrap-diagnostics` - load whenever the session-start digest's bootstrap or network-checks section prints an actionable diagnostic line (`MISSING:`, `MISSING_MANUAL:`, `BACKEND_INVALID:`, `NEEDS_GH_AUTH`, `TANGLE:`, `VAULT_DRIFT:`, `UPSTREAM:`, `GBRAIN_SERVING_CREDENTIAL:`, `GBRAIN_PIN:`, `GBRAIN_CAPTURE:`, `STARTUP_MEMORY_BUDGET:`, `CREW_DISPATCH:` (invalid or backend mismatch), `FLEET_SYNC:`, `BOARD_SWEEP:`, `NETWORK_CHECKS:`, `HOME_SUMMARY:`, `BACKLOG_RECONCILE:`, `ENDPOINT_BINDING_MIGRATION:`, `RUN_ATTRIBUTION:`, `SECONDMATE_SYNC:`, `SECONDMATE_LIVENESS:`, `SECONDMATE_HANDOFF:`, `NUDGE_SECONDMATES:`, `USAGE_STORE:`, or `FMX:`), or when `BOOTSTRAP_INFO:` says an interrupted backlog cleanup may have left an endpoint or local copy; silence and other `BOOTSTRAP_INFO:` facts need no load.
 - `diagnostic-reasoning` - load before scoping a reported bug and before acting on a diagnostic report.
-- `design-profile` - load before scaffolding, dispatching, answering, completing, or cleaning up an interactive design task whose tracked deliverable is an ADR.
+- `design-profile` - load before scaffolding, dispatching, answering, completing, or cleaning up a one-conversation design task whose tracked deliverable is a short ADR.
 - `ask-user-authority` - load before deciding any ask-user finding, regardless of the project's `yolo` posture.
 - `quota-array-dispatch` - load before choosing among a matched crew-dispatch profile array from current quota-axi default TOON.
 - `harness-adapters` - load before spawning or recovering a crewmate or secondmate, handling a trust dialog, sending a harness-specific skill invocation, interrupting or exiting an agent, resuming an exited agent, or verifying a new harness adapter.

README.md

@@ -44,7 +44,7 @@ Launching a supported harness inside it for your primary session instantiates yo
 - **One liaison** - you talk only to the first mate; it dispatches, supervises, escalates only real decisions, and reports plain outcomes.
 - **A visible crew** - every crewmate works in its own tmux window, Herdr tab, or experimental zellij tab, cmux workspace, or Orca terminal you can watch or type into; the first mate reconciles.
 - **Disposable worktrees** - each task runs in a clean [treehouse](https://github.com/kunchenguid/treehouse) git worktree, or an Orca-managed worktree when `backend=orca`, so parallel work on one repo never collides.
-- **Three task shapes** - ship tasks deliver authorized changes; design tasks run an interactive decision interview and land an ADR; scout tasks leave standalone investigation reports when the intake contract warrants separate research.
+- **Three task shapes** - ship tasks deliver authorized changes; design tasks run one planning conversation and land a short ADR for a consequential tradeoff; scout tasks leave standalone investigation reports when the intake contract warrants separate research.
 - **Explicit project modes** - each project ships via `no-mistakes`, `direct-PR`, or `local-only`, with an optional `+yolo` merge-autonomy flag.
 - **Optional secondmates** - opt in to persistent second mates that run from isolated firstmate homes with their own `FM_HOME`, state, projects, and session lock, either locally or as a whole home on an SSH-reachable host, with guarded updates and recovery that never turns an unavailable remote route into a local replacement.
 - **Event-driven, zero-token supervision** - a bash watcher sleeps on the fleet and wakes the first mate only when something needs you; verified primary harnesses also get a turn-end backstop that blocks or follows up on a blind stop when work is under way and supervision is not live.

bin/fm-brief.sh

@@ -48,11 +48,14 @@
 #   Either way fm-spawn.sh copies the explicit markers into task metadata, where
 #   bin/fm-issue-comment.sh reads the recorded PR target to decide whether it may
 #   write firstmate's own living status comment to that tracker.
-#   --design writes the interactive design contract: the worker reads the
-#   installed mattpocock grilling and domain-modeling skills, asks one
-#   evidence-first question at a time through firstmate, and produces a tracked
-#   ADR through the selected delivery mode. The plugin is read in place and is
-#   never installed, updated, copied, vendored, pinned, or modified here.
+#   --design writes one planning conversation whose only tracked project
+#   deliverable is a short ADR: the worker researches facts, may use an optional
+#   visual proposal, and reads the installed mattpocock grilling and
+#   domain-modeling skills selectively for dependency-aware questioning and
+#   terms. It asks one evidence-first question at a time through firstmate and
+#   ships the ADR through the selected delivery mode. The plugin is read in
+#   place and is never installed, updated, copied, vendored, pinned, or
+#   modified here. Plugin lifecycle is captain-owned outside this repository.
 #   --scout writes the scout contract instead: the deliverable is a report at
 #   data/<task-id>/report.md (no branch, no push, no PR) and the worktree is scratch.
 #   --secondmate writes a persistent secondmate charter. The project list
@@ -436,7 +439,7 @@ BRIEF="$DATA/$ID/brief.md"
 [ -e "$BRIEF" ] && { echo "error: $BRIEF already exists" >&2; exit 1; }
 if [ "$KIND" = design ]; then
   "$FM_ROOT/bin/fm-design-skills.sh" check >/dev/null || {
-    echo "error: --design requires the captain-installed mattpocock grilling and domain-modeling skills; do not install or copy them from a worker" >&2
+    echo "error: --design requires the captain-owned mattpocock grilling and domain-modeling skills; do not install or copy them from a worker" >&2
     exit 1
   }
 fi
@@ -1049,26 +1052,34 @@ if [ "$KIND" = design ]; then
   OUTPUT_KIND=design
   IFS= read -r -d '' DESIGN_SECTION <<EOF || true
 # Design profile
-This is an interactive DESIGN task whose only tracked project deliverable is one architectural decision record.
+This is one DESIGN planning conversation whose only tracked project deliverable is one short architectural decision record.
 Do not implement the resulting design or make unrelated project changes.
 Do not create or modify any other tracked project file, including \`AGENTS.md\` or \`CLAUDE.md\`.
+Do not stack a separate Kun workflow, a separate Matt workflow, and this ADR as three passes.
 
-Read and follow \`$FM_ROOT/.agents/skills/design-profile/SKILL.md\` before beginning the interview.
+Read and follow \`$FM_ROOT/.agents/skills/design-profile/SKILL.md\` before beginning the conversation.
 At dispatch Firstmate prepends the exact \`grilling\` and \`domain_modeling\` paths from the resolver call whose plugin release it records for this task.
 Read only those dispatch-pinned paths, never resolve the plugin again from this worker, and stop with the binding's blocker if either exact file is unavailable.
 This direct file-binding contract is identical on Claude, Codex, and Pi and does not depend on harness-specific skill-command spelling.
 Never install, update, copy, vendor, pin, or modify that plugin from this task.
-Use those skills for modeling and interrogation only.
+Plugin lifecycle is captain-owned outside this repository; do not add a competing updater here.
+Use those skills selectively for the design tree, the next unblocked question, and domain terms.
+Do not import grill-with-docs, to-spec, to-tickets, wayfinder, implement, or CONTEXT.md from that plugin.
 Do not create or update \`CONTEXT.md\`, even if a dependency instructs you to do so.
 Record every resolved term only in the ADR so it remains the sole tracked project deliverable.
 
 Investigate factual questions from repository evidence before asking for a decision.
+If an ambiguous choice is clearer as a diagram or interactive proposal, you may use lavish-axi in this same conversation.
+Do not require a visual review, and do not start a separate visual-review workflow for a well-specified ADR ask.
 Ask exactly one decision question at a time, with one stable key, the evidence, and your recommended answer.
+Choose that question as the next unblocked decision on the design tree; do not batch the whole frontier.
 Append \`needs-decision [key=<stable-slug>]: {one question} Recommendation: {answer and evidence}\`, then stop and wait.
 Never batch questions, answer on behalf of firstmate, or proceed while the current key is unresolved.
 When an answer arrives, append \`resolved [key=<same-stable-slug>]: {decision returned by firstmate}\` and \`working: continuing the design interview\` in the same breath, then capture the decision in the ADR.
 State the converged decision back to firstmate before drafting the ADR.
 
+Write a short ADR only when the dispatched domain-modeling skill's ADR bar is met.
+If the conversation shows a routine configuration change rather than a consequential architectural tradeoff, append \`needs-decision\` rather than padding a ceremonial ADR.
 Use an existing project ADR convention when one exists.
 Otherwise use \`docs/adr/NNNN-<slug>.md\`, incrementing the highest existing number.
 The ADR must stand alone with context, decision, rationale, relevant alternatives, and non-obvious consequences.