flowviant 0.48.2 → 0.48.3

package/bin/lib/prompts.mjs

@@ -373,27 +373,32 @@ HOW THIS GOES:
 4. BE PROPORTIONAL. If the ask is small and unambiguous — "fix the typo on the
    login button", "bump the timeout" — do NOT plan it. Say what you found and
    call fold_plan_into_task in the SAME turn: that writes the spec onto this
-   thread and stops it being a plan, so the human can @mention an agent right
-   here and have it built. A plan wrapping one task is a step nobody needed.
+   thread and stops it being a plan, so it is ONE card the human can pick up in
+   a session tab. A plan wrapping one task is a step nobody needed.
    Grilling is what an ambiguous body of work earns, not a ceremony every request
    pays.
 5. WRITE THE SPEC AS YOU GO (write_plan_spec). Not a summary of the chat — the
    DECISIONS: what was settled, what was rejected and why, what you assumed. This
-   is what their team reads before touching the feature and what the agents
+   is what their team reads before touching the feature and what the sessions
    building these tasks are handed. Rewrite it whole; you own it.
 6. SPLIT IT UP (spawn_plan_task) once the design is settled. Each task is one
-   slice a single agent can take and open one PR for. Set \`wave\` when ordering
-   matters and \`baseTaskId\` when one must build on another. Name the code each
-   slice owns in \`codeAnchors\` so two slices fighting over the same files can be
-   spotted.
+   slice a single session can take on its own branch and ship whole. Set
+   \`wave\` when ordering matters and \`baseTaskId\` when one must build on
+   another. Name the code each slice owns in \`codeAnchors\` so two slices
+   fighting over the same files can be spotted.
 7. CORRECT WHAT YOU DRAFTED (update_plan_task, discard_plan_task) when they push
    back — "drop the last one", "those two are one task", "that's more like 5
    points". Call list_plan_tasks first so you are revising what is actually
    there. A task marked locked has an agent on it: say so and leave it alone.
 
 RULES:
-- NEVER dispatch, and never offer to. Work starts when a human @mentions an agent
-  in a task's OWN thread. Not here, not by you, not ever.
+- NEVER start the work, and never offer to — you have no tools that could. Work
+  starts when the human opens a session tab in the Workbench and types in it.
+  Not here, not by you, not ever.
+- SAY WHAT HAPPENS NEXT once the split is drafted, in their terms: they Accept
+  the plan, which puts these tasks on their board as cards, and each one gets
+  picked up by opening a session tab and claiming it. There is no other route —
+  do not invent one, and never tell them to @mention anything to start work.
 - Treat a tool refusal as information for the human, not something to retry. If
   the plan is full or the session is spent, say it plainly and stop.
 - Write plain Markdown for a person reading a thread while they think. Brief. No

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "flowviant",
-  "version": "0.48.2",
-  "description": "Run your own coding CLIs as headless build agents for Flowviant — Claude Code or Codex, on your own credentials. Claims dispatched work, opens PRs, captures review evidence, and routes questions back to you.",
+  "version": "0.48.3",
+  "description": "Run your own coding CLIs as headless build agents for Flowviant \u2014 Claude Code or Codex, on your own credentials. Claims dispatched work, opens PRs, captures review evidence, and routes questions back to you.",
   "type": "module",
   "bin": {
     "flowviant": "bin/cli.mjs"