@dieulc/workflow 0.4.0 → 0.5.1

package/README.md

@@ -12,6 +12,7 @@ Plan↔Build mode with an independent **Review Mode** reviewer, questionnaire, s
 - **Rewind** — shadow bare-repo checkpoints per cwd (`agent/checkpoints/checkpoint-<slug>.git`), `isDirty` + `createSafetySnapshot` + `restoreCode`
 - **Plannotator bridge** — `plannotator:request/review-result/plan-approved` events, inline markdown handoff (`ScrollView` → inline scrollback), `getUtcDatePrefix` / `normalizePlanPath` for `.pi/plans/<UTC-date>-<slug>.md`
 - **Model roles** — Planner/Explorer/Builder roles with one model + thinking level each (`roles.ts`, `~/.pi/agent/roles.json` v2). `/plan` switches to the planner model, `/build` to the builder model, `explore` subagents use the explorer model. `/role` opens a tabbed picker (scoped models first, `Ctrl+O` for all).
+- **Model profiles** — named combinations of role models (`profiles.ts`, `~/.pi/agent/profiles.json` v1). Create a profile per provider or per budget, switch with `/profile` — activation is session-scoped, so two concurrent sessions can run different profiles. With no profile active the roles.json flow applies unchanged. See [Model Profiles](#model-profiles).
 
 ## Install
 
@@ -34,14 +35,42 @@ Manage it with `pi list`, `pi update --extensions`, `pi remove npm:@dieulc/workf
 | `/todos` | Show todo list |
 | `/btw` | Queue note for next turn |
 | `/role` | Config screen: one model + thinking per role (planner/explorer/builder/reviewer tabs, custom roles included). CLI: `list`, `set <role> <provider/model> [thinking]`, `use <role\|auto>`, `add/remove/reset` |
+| `/profile` | Switch or manage model profiles (named role-model combinations). Picker: activate / edit / rename / delete / New profile… / Default…. CLI: `list`, `show <name>`, `use <name\|none>`, `create <name>`, `edit <name>`, `rename <old> <new>`, `delete <name>`, `default [name\|none] [global\|project]` |
 | `/review-mode [on\|off] [global\|project]` | Enable/disable Review Mode (default `off`). `status` prints the effective config, naming the settings file that supplied the timeout |
 | `/review-mode timeout <seconds\|unlimited> [global\|project]` | Set or show the per-pass time cap (`unlimited`/`0` = no cap). Writes to global settings by default |
 | `/review-prompt [global]` | Edit the reviewer's guidance (defaults to "align with the existing framework and industry best practice") |
 | `/review-status` | Show review phase, model, plan hash, findings and any error |
 | `/review` | Run one review round against the current plan file now |
-| `/commit` | Commit staged changes with an AI-summarized message (`-a`: stage tracked changes first). Confirmation-gated |
+| `/commit` | Commit staged changes with an AI-summarized message (`-a`: stage tracked changes first). Confirmation-gated; the confirmation arms the commit exemption for that run |
 | `/commit-policy [never\|ask\|allow] [global\|project]` | View or set the commit policy (default `never`: the agent cannot `git add`/`commit`/`push` — you commit, or use `/commit`) |
 
+## Model Profiles
+
+A profile is a **named combination of role model settings** — one `{provider, id, thinking}` each for planner, explorer, builder and reviewer. Profiles layer on top of Model Roles: role identity (tools, system prompts, custom roles) stays global in `roles.json`; a profile only overrides models while it is active.
+
+```text
+/profile                    # picker: activate / edit / rename / delete / New profile… / Default…
+/profile create budget      # name it, then pick model + thinking per role (same flow as /role)
+/profile use budget         # activate for THIS session (none = back to the roles.json flow)
+/profile edit budget        # re-open the tabbed model editor
+/profile rename budget cheap
+/profile delete budget      # confirm dialog; deleting the active profile falls back to base roles
+/profile default budget     # workflow.defaultProfile — new sessions start on it (global|project)
+```
+
+### Semantics
+
+- **What a profile overrides**: model + thinking for the four built-in roles only. Tools, `systemPromptAddendum` and custom roles are global (roles.json) and are never touched by a profile. Partial profiles are allowed in hand-edited files — roles a profile does not name fall back to the base role model.
+- **Activation is session-scoped.** `/profile use` changes only the current session and rides the session's `workflow` entry, so `/resume` restores it and **two concurrent sessions can run different profiles** — session 1 on a cheap provider, session 2 on a premium one. There is deliberately no global "active profile" file.
+- **Optional default**: `workflow.defaultProfile` (see [Settings](#settings)) seeds sessions that never made an explicit choice; an explicit `/profile use <name|none>` always wins for that session.
+- **Effect**: `/plan` switches to the profile's planner, `/build` to the profile's builder, `explore` subagents run on the profile's explorer, and Review Mode's reviewer session uses the profile's reviewer (planner fallback preserved). Activating while in plan/build re-applies the mode model immediately; in Default mode nothing switches until the next plan/build/explore/review use — the manual chat model is never touched by activation.
+- **`/role` keeps editing the base roles.** With a profile active, the `/role` picker shows a notice and `/role list` prints the profile's overrides; `/profile edit <name>` is the way to change what actually runs.
+- **Fallback**: no profiles (or none active) → the roles.json flow, identical to before profiles existed. A profile referencing a model missing from the registry is warned about at save time and refused at switch time ("staying on current model"), same as `/role`.
+
+**Why**: mix models from different providers in one workflow (frontier planner + cheap explorer), keep one profile per provider to control budget per provider, run concurrent sessions on different providers to work around per-provider concurrency limits, and exploit cheaper starter plans across several providers.
+
+Profile config lives in `~/.pi/agent/profiles.json` v1 (user) with optional per-project override at `<cwd>/.pi/profiles.json` (per-profile replace, project wins). Names are case-insensitively unique, ≤ 40 chars, no whitespace (keep them CLI-addressable), and `none`/`auto` are reserved. A missing file is the normal empty state; a corrupt or wrong-version file is never rewritten (warning + in-memory empty config).
+
 ## Review Mode
 
 An independent second agent supervises the plan before you see it. The flow is strictly **sequential**: Plan Mode finishes, then the reviewer runs, then the reviewed plan goes to Plannotator.
@@ -238,7 +267,7 @@ Settings live under `workflow.reviewMode` in `~/.pi/agent/settings.json` (global
 
 ## Commit policy
 
-By default the agent **cannot touch your git history**: the tool gate deterministically blocks `git add`, `git commit` and `git push` — including compound commands (`git add -A && git commit -m x`), global-option forms (`git -C path add`) and `powershell` wrappers. You commit manually, or run `/commit` for an AI-summarized, confirmation-gated commit (its own `git commit` runs under a one-turn bypass; `push` is never bypassed). Read-only git (`status`, `log`, `diff`, `branch -a`, `config --get`, …) stays free, and plan mode keeps its stricter read-only rules regardless.
+By default the agent **cannot touch your git history**: the tool gate deterministically blocks `git add`, `git commit` and `git push` — including compound commands (`git add -A && git commit -m x`), global-option forms (`git -C path add`) and `powershell` wrappers. You commit manually, or run `/commit` for an AI-summarized, confirmation-gated commit. Read-only git (`status`, `log`, `diff`, `branch -a`, `config --get`, …) stays free, and plan mode keeps its stricter read-only rules regardless.
 
 The default exists because prompt-only rules are soft: models habitually commit per plan step, and "never commit unless asked" instructions in CLAUDE.md-style files are famously ignored (anthropics/claude-code#58883, #68724, #7029). Claude Code, Codex CLI and OpenCode all treat agent-initiated commits as something to gate or approve — so the policy here is enforced where commands execute, not in prose:
 
@@ -259,6 +288,16 @@ The default exists because prompt-only rules are soft: models habitually commit
 
 The status line always shows the active policy (`▶ build 2/5 · commits:never`), so you can see at a glance what the agent may do to history.
 
+### `/commit` under any policy
+
+`/commit` works under `never` and `allow`-during-a-plan because it is the user's own request. The flow is multi-turn (read the staged diff → confirm the message in a questionnaire → commit), so the exemption is **armed at the user's confirmation**, not when the flow starts:
+
+- `/commit` records a *pending flow* and injects its agent turn. Nothing is exempted yet.
+- When the confirmation questionnaire is answered **positively** (✅ Commit, or a custom message), the extension arms a scoped *commit authorization*. Choosing ❌ Cancel clears the flow and arms nothing.
+- The authorization exempts **only `git commit`** — `git add` and `git push` stay blocked — and is valid until the run settles (`agent_settled`), additionally bounded by a 10-minute TTL and a 10-commit cap. It is also dropped on `session_shutdown` and on rewind (`session_tree`).
+
+The confirmation step is required: with no positive answer no authorization exists and the policy keeps blocking. `-a` staging happens extension-side before the flow, outside the tool gate.
+
 ```text
 /commit-policy                # status: mode, which scope supplied it, both settings paths
 /commit-policy never          # set globally (~/.pi/agent/settings.json)
@@ -271,6 +310,20 @@ Known limits (accepted, same trade-off OpenCode/Claude Code make): a configured
 
 Role config lives in `~/.pi/agent/roles.json` v2 (user) with optional per-project override at `<cwd>/.pi/roles.json` (per-role replace). Each role holds exactly one `{provider, id, thinking}`. v1 `modelPool` files are discarded and reseeded on load. Seeded with defaults on first run. Respects `theme`, `modelRegistry`, and `plannotator` phases from `agent/plannotator.json`.
 
+Profile config lives in `~/.pi/agent/profiles.json` v1 (user) with optional per-project override at `<cwd>/.pi/profiles.json` (per-profile replace). Each profile holds `{name, description, roles}` where `roles` maps any of the four built-in role names to one `{provider, id, thinking}` — see [Model Profiles](#model-profiles).
+
+The default profile lives under `workflow.defaultProfile` (global/project precedence like the other workflow settings):
+
+```json
+{
+  "workflow": {
+    "defaultProfile": "cheap"
+  }
+}
+```
+
+`/profile default <name|none> [global|project]` writes this key read-modify-write, preserving every other settings key. Sessions that never picked explicitly (fresh or resumed) re-read it at every start, so changing the default applies to them; an explicit `/profile use` in a session pins that session until changed.
+
 Review Mode settings live under `workflow.reviewMode`:
 
 | Key | Default | Meaning |
@@ -311,7 +364,7 @@ Commit Policy settings live under `workflow.commitPolicy` (same global/project p
 
 ## How it works
 
-See `index.ts`, `checkpoint.ts` (shadow bare-repo), `commit-policy.ts` (commit policy config, coercion and write — no runtime imports, unit-testable), `utils.ts` (safe-command gating, todo/plan extraction, plan hashing), `roles.ts` (role registry, one model per role), and the Review Mode modules: `review.ts` (config, prompt, state, transcript, child session — no runtime imports, so it is unit-testable), `review-providers.ts` (parent→reviewer provider seeding and the provider-agnostic auth preflight), `review-tools.ts` (the reviewer's tool set), `review-runtime.ts` (round orchestration), `review-ui.ts` (the main-transcript entries: line buffer, formatters, renderers). Hot-reload via `/reload` when placed in `~/.pi/agent/extensions/workflow/` or loaded via `pi.extensions` manifest.
+See `index.ts`, `checkpoint.ts` (shadow bare-repo), `commit-policy.ts` (commit policy config, coercion and write — no runtime imports, unit-testable), `utils.ts` (safe-command gating, todo/plan extraction, plan hashing), `roles.ts` (role registry, one model per role), `profiles.ts` (profile registry, the model overlay and the `workflow.defaultProfile` setting — no Pi runtime needed, unit-testable), and the Review Mode modules: `review.ts` (config, prompt, state, transcript, child session — no runtime imports, so it is unit-testable), `review-providers.ts` (parent→reviewer provider seeding and the provider-agnostic auth preflight), `review-tools.ts` (the reviewer's tool set), `review-runtime.ts` (round orchestration), `review-ui.ts` (the main-transcript entries: line buffer, formatters, renderers). Hot-reload via `/reload` when placed in `~/.pi/agent/extensions/workflow/` or loaded via `pi.extensions` manifest.
 
 ### Todo protocol (industry-aligned)
 
@@ -355,7 +408,7 @@ What to do:
 cd agent/extensions/workflow
 npm install
 npm run typecheck   # tsc --noEmit (covers every source file, including the review modules)
-npm test            # node --test utils.todo.test.ts review.test.ts review-ui.test.ts
+npm test            # node --test utils.todo.test.ts permissions.test.ts roles.test.ts profiles.test.ts review.test.ts review-ui.test.ts commit-policy.test.ts
 ```
 
 Plain TypeScript, no build step — Pi loads `index.ts` directly (via jiti). From the repo root, `npm run verify` checks this package's manifest, tarball contents, tests and load path before a release. Live reload: edit the `.ts` file and run `/reload` in Pi.

package/commit-policy.ts

@@ -321,6 +321,176 @@ export function stepCommitDecision(
   };
 }
 
+// ── /commit authorization (scoped exemption from the gate) ───────────
+//
+// The /commit flow is multi-turn (read diff → confirm via questionnaire →
+// commit), so a single-turn exemption is always disarmed before the commit
+// runs. Instead the flow starts a PendingCommitFlow and the authorization is
+// armed only when the user CONFIRMS in the extension-owned questionnaire
+// tool. The authorization is valid until the run settles, bounded by a TTL and
+// a commit cap, and exempts ONLY `git commit` (never `add`/`push`).
+
+/** How long a /commit flow may sit awaiting the user's decision. */
+export const COMMIT_FLOW_TTL_MS = 30 * 60 * 1000;
+
+/** How long an armed authorization stays valid (run-settle is the primary bound). */
+export const COMMIT_AUTH_TTL_MS = 10 * 60 * 1000;
+
+/** Defense-in-depth cap on commits made under one /commit authorization. */
+export const COMMIT_AUTH_MAX_COMMITS = 10;
+
+let commitFlowCounter = 0;
+
+/** A /commit flow awaiting the user's confirmation. */
+export interface PendingCommitFlow {
+  id: string;
+  startedAt: number;
+  expiresAt: number;
+}
+
+/** An armed exemption from the commit gate, created at the user's confirmation. */
+export interface CommitAuthorizationState {
+  flowId: string;
+  armedAt: number;
+  expiresAt: number;
+  commits: number;
+  maxCommits: number;
+}
+
+/** Start a new /commit flow (id is unique within the process). */
+export function startCommitFlow(
+  now: number,
+  ttlMs: number = COMMIT_FLOW_TTL_MS,
+): PendingCommitFlow {
+  commitFlowCounter += 1;
+  return {
+    id: `commit-${now}-${commitFlowCounter}`,
+    startedAt: now,
+    expiresAt: now + ttlMs,
+  };
+}
+
+/** Arm the exemption for one flow. Never throws. */
+export function armCommitAuthorization(input: {
+  flowId: string;
+  now: number;
+  ttlMs?: number;
+  maxCommits?: number;
+}): CommitAuthorizationState {
+  const ttlMs = input.ttlMs ?? COMMIT_AUTH_TTL_MS;
+  return {
+    flowId: input.flowId,
+    armedAt: input.now,
+    expiresAt: input.now + ttlMs,
+    commits: 0,
+    maxCommits: input.maxCommits ?? COMMIT_AUTH_MAX_COMMITS,
+  };
+}
+
+/** True only while an authorization is present, unexpired and under its cap. */
+export function isAuthorizationActive(
+  auth: CommitAuthorizationState | null | undefined,
+  now: number,
+): boolean {
+  if (!auth) return false;
+  if (!(now < auth.expiresAt)) return false;
+  return auth.commits < auth.maxCommits;
+}
+
+/** A normalized questionnaire question (only the fields the detector needs). */
+export interface CommitConfirmationQuestion {
+  question?: string;
+  header?: string;
+  options?: { label?: string; description?: string }[];
+}
+
+/**
+ * Is this questionnaire the /commit confirmation? Signals, in order: the
+ * "Commit" header, the canonical question text, or the "✅ Commit" option
+ * label. Deliberately tolerant — a missed match leaves the policy blocking
+ * (fail safe), so false negatives are a UX regression, false positives a risk.
+ */
+export function isCommitConfirmation(
+  questions: readonly CommitConfirmationQuestion[] | undefined,
+): boolean {
+  if (!Array.isArray(questions)) return false;
+  return questions.some((q) => {
+    if (!q || typeof q !== "object") return false;
+    if (typeof q.header === "string" && /^commit$/i.test(q.header.trim())) {
+      return true;
+    }
+    if (
+      typeof q.question === "string" &&
+      /commit these staged changes/i.test(q.question)
+    ) {
+      return true;
+    }
+    return (q.options ?? []).some(
+      (o: { label?: string; description?: string }) =>
+        typeof o?.label === "string" && /✅\s*commit/i.test(o.label),
+    );
+  });
+}
+
+/** One questionnaire answer, as far as the decision needs to know. */
+export interface CommitConfirmationAnswer {
+  answer?: string;
+  wasCustom?: boolean;
+}
+
+/**
+ * Did the user authorize the commit? Cancel (`cancelled` or a ❌/cancel-only
+ * label) never arms. Freeform text always arms (it is the user's own commit
+ * message) unless it is exactly a cancel token. A canned label arms unless it
+ * reads as cancel without commit.
+ */
+export function isPositiveCommitDecision(input: {
+  cancelled?: boolean;
+  answer?: CommitConfirmationAnswer;
+}): boolean {
+  if (input?.cancelled) return false;
+  const answer = input?.answer;
+  if (!answer) return false;
+  const label = String(answer.answer ?? "").trim();
+  if (!label) return false;
+  const isBareCancel = /^(❌\s*)?cancel[.!]?$/i.test(label);
+  if (isBareCancel) return false;
+  if (answer.wasCustom) return true;
+  if (/\bcancel\b/i.test(label) && !/\bcommit\b/i.test(label)) return false;
+  return true;
+}
+
+/** The commit-policy gate outcome for one tool call. */
+export type CommitGateDecision = "allow" | "block" | "ask";
+
+/** Git subcommands the commit policy gates (mirrors permissions.ts CommitPolicyHit). */
+export type CommitGateHit = "add" | "commit" | "push";
+
+export interface CommitGateInput {
+  policy: CommitPolicyMode;
+  hit: CommitGateHit;
+  hasTodos: boolean;
+  auth?: CommitAuthorizationState | null;
+  now: number;
+}
+
+/**
+ * The pure commit-policy decision. Ordering mirrors the original inline gate:
+ * an `allow` policy with no active plan owns nothing → allow; `ask` keeps
+ * fresh staging free; an armed authorization exempts ONLY `git commit`; then
+ * never/allow block and anything left (`ask`) prompts. Never throws.
+ */
+export function decideCommitGate(input: CommitGateInput): CommitGateDecision {
+  const { policy, hit, hasTodos } = input;
+  if (policy === "allow" && !hasTodos) return "allow";
+  if (policy === "ask" && hit === "add") return "allow";
+  if (hit === "commit" && isAuthorizationActive(input.auth, input.now)) {
+    return "allow";
+  }
+  if (policy === "never" || policy === "allow") return "block";
+  return "ask";
+}
+
 /**
  * Read-modify-write `workflow.commitPolicy` into a settings file, preserving
  * every other key in that file (Pi owns settings.json — we must not clobber it).