@widnyana/design-thinking 0.0.3 → 0.0.6

package/README.md

@@ -61,6 +61,7 @@ pi -e ./pi-packages/design-thinking
 |---|---|
 | `/dt` | Toggle Design Thinking mode. While on, plans and reviews render as Design Graphs. Persists across restarts. |
 | `/dt on\|off\|status` | Set or query the mode explicitly. |
+| `/dt approve\|deny` | Arm/revoke file edits for the next agent run — run `approve` after a presented graph to let the implementation run edit, `deny` to re-lock. |
 | `/dt <prompt>` | Turn the mode **on** (never off), then run `<prompt>` under it — graph and clarifying questions first, implementation after your go-ahead. |
 | `/cg <module \| task>` | Generate a call graph: extract the graph existing code implements, or sketch one for a task. |
 | `/cg-plan <task>` | Design before code — full Design Graph, then implement to match it. |

package/extensions/design-thinking.ts

@@ -15,6 +15,7 @@
  *   /dt            toggle Design Thinking mode
  *   /dt on|off     set explicitly
  *   /dt status     show current state
+ *   /dt approve|deny  arm/revoke file edits for the next agent run
  *   /dt <prompt>   turn mode ON (never off), then run <prompt> as a user
  *                  message — graph + clarifying questions before implementation
  *
@@ -42,7 +43,7 @@ const REF_DIR = path.resolve(
 	"references",
 );
 
-/** Compact distilled prompt block injected while active (~33 lines). */
+/** Compact distilled prompt block injected while active. */
 const DISTILLED = `
 DESIGN THINKING MODE — active.
 Read the problem. Draw the data flow as a call graph. Write code that IS the graph.
@@ -65,7 +66,9 @@ Rules:
   refactor — the model does NOT get to reclassify the request): render the
   Design Graph in Graph Protocol form and any clarifying questions FIRST;
   ZERO file edits until the user approves the design. Reading/exploring code
-  first is fine; the FIRST edit is not allowed before the graph.
+  first is fine; the FIRST edit is not allowed before the graph. Once the
+  user runs /dt approve, edits are armed for the NEXT run: implement the
+  approved design without re-presenting the graph.
 - Design, plan, and review answers must render a Design Graph — fixed
   sections: PROBLEM, SHAPES, GRAPH, CARDINALITY, BOUNDARIES, BEHAVIOR, SCOPE,
   TEST LAYERS, VERDICT.
@@ -82,15 +85,32 @@ Skills load BY NAME into the agent (/skill:<name>); the files above are named
 by stem, NOT by skill name. Exact mapping:
   /skill:graph-protocol → protocol.md   /skill:design-method → method.md
   /skill:design-graph → design-graph.md
+  The extension blocks write/edit tools mechanically until the user runs
+  /dt approve — it arms the NEXT run, cleared when that run ends. Re-approve
+  per implementation round. Present the graph first.
 NEVER read references/<skill-name>.md — no such files exist.
 `.trim();
 
+// pi's file-edit tools — the mechanical gate's scope ("file edits"). Bash
+// stays open for read-only exploration. apply_patch/multiedit are Claude Code
+// tool names that never fire in pi; keep this list to real pi mutators.
+const MUTATING_TOOLS: Record<string, true> = {
+	write: true,
+	edit: true,
+};
+
 interface DtState {
 	enabled: boolean;
 }
 
+const GATE_REASON =
+	"Design Thinking mode is ON: present the Design Graph (Graph Protocol) and wait for user approval before file edits. The user arms the NEXT run with /dt approve; the approval clears when that run ends.";
+
 export default function designThinkingExtension(pi: ExtensionAPI) {
 	let enabled = false;
+	// Armed by /dt approve for the NEXT agent run. Cleared when that run ends
+	// (agent_end), by /dt deny, or when the mode turns off. Not persisted.
+	let editsApproved = false;
 
 	function applyStatus(ctx: ExtensionContext) {
 		ctx.ui.setStatus(
@@ -129,15 +149,35 @@ export default function designThinkingExtension(pi: ExtensionAPI) {
 		ctx.ui.setStatus("design-thinking", undefined);
 	});
 
-	// /dt — the Design Thinking tool. Toggles mode, or /dt on|off|status.
+	// /dt — the Design Thinking tool. Toggles mode; on|off|status set/query;
+	// approve|deny arm/revoke file edits; anything else runs as a prompt with mode on.
 	pi.registerCommand("dt", {
-		description: "Design Thinking mode: /dt toggles, on|off|status set/query, anything else runs as a prompt with mode on",
+		description: "Design Thinking mode: /dt toggles, on|off|status set/query, approve arms the next run for file edits, deny revokes; anything else runs as a prompt with mode on",
 		handler: async (args, ctx) => {
 			const arg = (args ?? "").trim();
 			const lower = arg.toLowerCase();
 
 			if (lower === "status") {
-				ctx.ui.notify(`Design Thinking mode: ${enabled ? "on" : "off"}`, "info");
+				ctx.ui.notify(`Design Thinking mode: ${enabled ? "on" : "off"}${editsApproved ? " (file edits armed for the next run)" : ""}`, "info");
+				return;
+			}
+
+			if (lower === "approve") {
+				if (!enabled) {
+					ctx.ui.notify("Design Thinking is OFF — nothing to approve. Run /dt on first.", "info");
+					return;
+				}
+				editsApproved = true;
+				ctx.ui.notify("Design Thinking: file edits armed (current or next run) — it may implement the approved design without re-presenting the graph", "info");
+				return;
+			}
+			if (lower === "deny") {
+				if (!editsApproved) {
+					ctx.ui.notify("Design Thinking: no approval in effect — file edits are already blocked", "info");
+					return;
+				}
+				editsApproved = false;
+				ctx.ui.notify("Design Thinking: file edits blocked again", "info");
 				return;
 			}
 
@@ -145,6 +185,7 @@ export default function designThinkingExtension(pi: ExtensionAPI) {
 			// mode and always turns the mode ON (never toggles it off); bare /dt toggles.
 			const prompt = /^(on|off|status)$/.test(lower) ? "" : arg;
 			enabled = lower === "on" || prompt ? true : lower === "off" ? false : !enabled;
+			if (!enabled) editsApproved = false;
 			persist();
 			applyStatus(ctx);
 			ctx.ui.notify(
@@ -164,11 +205,26 @@ export default function designThinkingExtension(pi: ExtensionAPI) {
 		},
 	});
 
-	// While active, append the distilled block to the system prompt every turn.
+	// While active, append the distilled block to the system prompt every run.
 	pi.on("before_agent_start", async (event) => {
 		if (!enabled) return undefined;
 		return {
 			systemPrompt: event.systemPrompt + "\n\n" + DISTILLED + "\n",
 		};
 	});
+
+	// An approved run consumes the approval: clear it when the run ends so
+	// later runs are gated again until the user re-approves with /dt approve.
+	pi.on("agent_end", async () => {
+		editsApproved = false;
+	});
+
+	// Hard gate: while enabled, file-edit tools are blocked until the user
+	// arms the next run with /dt approve. Prompt-level rules alone proved
+	// insufficient — this is the mechanical backstop.
+	pi.on("tool_call", async (event) => {
+		if (!enabled || editsApproved) return undefined;
+		if (!MUTATING_TOOLS[event.toolName]) return undefined;
+		return { block: true, reason: GATE_REASON };
+	});
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@widnyana/design-thinking",
-  "version": "0.0.3",
+  "version": "0.0.6",
   "type": "module",
   "description": "Design Thinking · Design Graph · Graph Protocol — a stack-agnostic design methodology for pi. Turns every plan, review, and refactor into an annotated call graph. Method originally by r17x; generalized to a pi package by widnyana.",
   "author": {
@@ -35,8 +35,11 @@
     "methodology",
     "call-graph"
   ],
+  "omp": {
+    "extensions": ["./extensions/design-thinking.ts"]
+  },
   "pi": {
-    "extensions": ["./extensions"],
+    "extensions": ["./extensions/design-thinking.ts"],
     "prompts": ["./prompts"],
     "skills": ["./skills"]
   },

package/skills/design-graph/SKILL.md

@@ -11,8 +11,8 @@ description: >
 # Design Graph — The Artifact
 
 A **Design Graph** is the annotated call graph of a concrete problem. It is
-what you produce when you apply [Design Thinking](/skill:design-method) to
-something, and it is written in [Graph Protocol](/skill:graph-protocol) notation.
+what you produce when you apply Design Thinking (see the `design-method` skill) to
+something, and it is written in Graph Protocol notation (see the `graph-protocol` skill).
 
 Nodes are functions. Edges are data flow. The annotations answer, for every
 node: what flows through it (A), how many times it runs (cardinality), where
@@ -97,5 +97,5 @@ VERDICT line.
 
 ## Worked example
 
-See the end of [Graph Protocol](/skill:graph-protocol) for a complete, non-TS worked
+See the end of the `graph-protocol` skill for a complete, non-TS worked
 example (a resumable URL-sync CLI in Python) with all sections filled.

package/skills/design-method/SKILL.md

@@ -25,7 +25,7 @@ implement only after the user approves the design. Reading and exploring code
 first is fine; the FIRST edit is not allowed before the graph. This rule is
 not optional and not stack-dependent.
 
-Render every result in [Graph Protocol](/skill:graph-protocol) format.
+Render every result in Graph Protocol format (see the `graph-protocol` skill).
 
 ```
 X → DesignGraph<A, E, R>